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)

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

https://starwiki.atlassian.net/browse/DS-12138

https://starwiki.atlassian.net/browse/KON-2963

Indholdsfortegnelse

Afgrænsning af epic

Pakke TILMELD-1 i Knuds liste - Beta roadmap DFDG

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne

Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår i tabellen.

(kopiér og indsæt manuelt i tabellen)

Automatisk oversigt

Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.

Beskrivelse af epic

Baggrund

Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til Tillmelding som jobsøgende følgende:

• I DFDG et skift til REST snitflade - og i denne epic med tilføjelse af en Update-funktion og hændelsesdato for tilmelding:

• På tilmelding som jobsøgende tilføjes hændelsesdato således, at sagsbehandler i jobcenter og a-kasse kan registrere, hvornår tilmeldingen forretningsmæssigt burde være sket fra, selvom tilmeldedato ikke kan være i fortiden. Ændringen foretages for at

  • lette bl.a. udbetalingen af dagpenge, hvis fx it-problemer i DFDG eller i lokale systemer har været årsag til, at en borger ikke kunne blive tilmeldt som jobsøgende

  • lette bl.a. udbetalingen af dagpenge, hvis sagsbehandler i jobcenter eller a-kasse af andre årsager end it-problemer ikke har fået tilmeldt borger den dag borger har henvendt sig i jobcenter eller a-kasse for at blive tilmeldt som jobsøgende

  • a-kassen via hændelsesdato kan registrere, hvis der for konkrete medlemmer dispenseres fra kravet om tilmelding

• En sanering i brug af ledighedsgrader ved tilmelding for mindske behovet for efterfølgende opdateringer

• I Jobnet en overgang til ny REST snitflade samt ny frontend arkitektur (denne opgave er ikke en del af denne epic, men vil blive specificeret i en efterfølgende epic)  

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

Jobcentre skal som hidtil kunne registrere tilmelding og afmelding som jobsøgende.

A-kasserne kan, jf. BAB, som hidtil vælge at tilbyde den service at de tilmelder ledige medlemmer som dagpengemodtagere. A-kasserne skal som hidtil kunne afmelde et medlem som jobsøgende, og herunder tilmelde personen uden ydelse, hvis personen ikke længere er ledig eller hvis medlemmet ikke skal have / kan få a-dagpenge.

23.04.2024: A-kassen skal, jf. databkg. § 66, som hidtil - når dimittender begynder at modtage arbejdsløshedsdagpenge - sikre, at personen er registreret som dagpengemodtager med tilmeldekategorien dagpengemodtager.

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

Her beskriver PO overordnet, hvordan epic'en forventes at påvirke aftagerne. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Serviceaftager skal overgå til ny REST snitflade, men kan i en overgangsperiode (indtil 2025-1) forblive på eksisterende SOAP service således, at serviceaftager mere frit kan tilrettelægge deres it-udvikling.

Perioden kan dog ændres, hvis der efterfølgende kommer forretningsændringer til servicen. En sådan efterfølgende ændring af perioden, vil fremgå i epic med de nye forretningsændringer.

Acc.kr. 1005.17.23.1 - Som STAR vil jeg have flyttet forretningsområdet for til- og afmelding som jobsøgende til forretningsdomænet (silo) VisiteringOgStatus inkl. at det lever op til de principper, der er fastsat

Løsningsmodel (internt STAR acc.kr.)

1005.17.23.2 - Som serviceaftager og STAR vil jeg have udstillet til- og afmelding som jobsøgende via ny REST snitflade med samme forretningslogik og operationer som den eksisterende SOAP service (UnemploymentEnrollmentService), dog udvidet med ny Update-funktion og hændelsesdato for tilmelding og med en sanering af kodelisten for ledighedsgrad)

Løsningsmodel

• Ny REST service i VisiteringOgStatus hvor det er muligt at tilmelde en borger som allerede har jobønsker

• Ny REST service i Komposite hvor man ifm. tilmeldingen kan oprette jobønsker

• Fejlkoder bevares

• Der ændres ikke i adgangsforhold til service/metoder 

• Tilmelding udstilles i VisiteringOgStatus.VisiteringOgStatusStatusService#GetPersonVisiteringOgStatusStatus med kun seneste tilmelding. I TilmeldingService findes GetTilmeldinger som er den fulde samling af tilmeldinger og GetTilmeldingshistorik.

• Ny forretning

  • Ny hændelsesdato (optionelt felt), der skal angive evt. anden dato (end registreringsdatoen) som tilmeldingen forretningsmæssigt skal være gældende gældende fra, selvom der som tilmeldedato kun kan registreres “dags dato”. Formålet er, at sagsbehandler (og STAR ifm. datagenopretninger) kan angive, hvornår tilmeldingen forretningsmæssigt burde have været gældende fra, selvom registreringen foretages “dags dato”. Fx hvis der har været it-problemer i lokale systemer eller i STARs systemer. Eller hvis a-kassen dispenserer fra kravet om tilmelding.

    • Validering ift. tilbagedatering af hændelsesdato:

      • A-kasser: Ingen begrænsning, da dispensationsbehovet for tilmelding ligge langt tilbage i fortiden

      • STAR: Ingen begrænsning (pga. testformål - og datagenopretninger)

      • Jobcentre: Op til 7 dage før registreringsdato. Fejlkode: 100033 - “Hændelsesdato må ikke ligge mere end 7 dage tilbage i tid ved jobcenterregistrering”

      • Hændelsesdato må ikke ligge tidligere end seneste afmeldedato. Fejlkode: 100034 - “Hændelsesdato må ikke ligge i tidligere tilmeldeperiode”

  • Ny Update-metode: UpdateTilmelding til brug for

    • afmelding

    • fjernelse af fremtidig afmelding således, at der ikke (længere) teknisk foretages en afmelding og samtidig gentilmelding i disse situationer

    • opdatering af ledighedsgrad således, at der ikke (længere) teknisk foretages en afmelding og samtidig gentilmelding i de situationer, hvor ledighedsgraden skal ændres

    • Validering:

      • Hændelsesdato må ikke ligge tidligere end seneste afmeldedato på tidligere tilmeldeforhold (se fejlkode ovenfor)

      • Ved afmelding validerer DFDG for, at alene afmeldedato og afmeldeårsag angives / opdateres. Fejlkode: 10032 - “Det er ikke lovligt at opdatere øvrige felter ifm. en afmelding”.

      • Når afmeldedato er i fortiden må der ikke opdateres på andet end hændelsesdato og berigtigelseskommentar. Fejlkode 100030 - “Når afmeldedato er i fortiden må kun hændelsesdato og berigtigelseskommentar opdateres”

      • Afmeldedato kan kun opdateres, herunder slettes, hvis den er i fremtiden - fejlkode 100031 ‘Afmeldedato må kun opdateres eller slettes hvis den er i fremtiden’

  • Sanering af registrering af ledighedsgrad ved tilmelding således, at der ikke ved tilmelding længere skal sondres mellem “fuldt ledig” og “delvis ledig”

VisiteringOgStatus.TilmeldingService

Ny REST service til oprettelse, opdatering og udlæsning af tilmeldinger:

STAR / DFDG anvender denne service internt til at registrere tilmelding, når der registreres tilmelding via Komposite.TilmeldingService med samtidig registrering af 'jeg-søger-job-som' stillingsbetegnelser og tilmelding. Eksterne aftagere kan også anvende denne service til at registrere tilmelding på borgere/medlemmer, der i forvejen har registreret 'jeg-søger-job-som' stillingsbetegnelser - og sagsbehandler ikke vil opdatere disse ifm. tilmeldingen.

CreateTilmelding og CreateTilmeldingMedIdentifier (30.04.2024)

Nye REST-metoder CreateTilmelding og CreateTilmeldingMedIdentifier til brug for tilmelding. Ved kald af førstnævnte metode tildeler DFDG et id til tilmeldingen. Ved kald af sidstnævnte metode tildeler det kaldende system et id til tilmeldingen.

UpdateTilmelding -

Nye valideringer:

• Se ovenfor under Ny forretning

Komposite.TilmeldingService -

Ny REST service til oprettelse af tilmeldinger med samtidig oprettelse af jobønsker:

Internt i STAR bruges denne også til at kunne tilmelde og straksbooke en borger som tilmelder sig på Jobnet

Nye valideringer:

• Se ovenfor under Ny forretning

1005.17.23.3 - Som serviceaftager vil jeg gerne beholde den eksisterende SOAP service (UnmeploymentEnrollmentService) uændret i en overgangsperiode indtil 2025-1 for at sikre en fleksibel overgang til ny snitflade

Løsningsmodel

• Eksisterende SOAP (UnmeploymentEnrollmentService) bevares uændret i en overgangsperiode indtil 2025-1 for at sikre en fleksibel overgang til ny snitflade

• Ekstern deltagelse i test af til- og afmelding ønskes - og af WSB / WSRM-beskeder

1005.17.23.4 - Som STAR vil jeg have dataleverancer i forhold til DOA tilpasset til det nye forretningsdomæne (silo)

Løsningsmodel (internt STAR acc.kr.)

• Initial load af data / Tilpasning af BI load til VisiteringOgStatus domænet (silo)

• TASS-Data til DOA påvirkes.

1005.17.23.5 - Som STAR vil jeg have at dokumentation for såvel servicelag og frontend lever op til STAR's principper på releasetidspunktet

Løsningsmodel (internt STAR acc.kr.)

• QA af regler fra kode mod dokumenteret regler og fejlkode

• Ajourfører dokumentation

Sider der skal rettes og QA er (liste er ikke udtømmende)

• Servicesnitflade 

1005.17.23.6 - Som STAR vil jeg have, at data er omfattet af dataløft og pseudonymisering mod testmiljøer

Løsningsmodel (internt STAR acc.kr.)

• Tilpasning af regler af for pseudonymisering og aftale hvornår data skal med i dataløft

• Systemforvalter tilretter pseudonymiseringsflow 

1005.17.23.7 - VisiteringOgStatus udstiller kodelisterne for til- og afmelding, herunder tilmeldekategorier og ledighedsgrad

Løsningsmodel 

• DFDG udstiller kodelister for 

  • Tilmeldekategori - ClientCategoryTypeIdentifierType

  • Ledighedsgrad - CurrentUnemploymentStatusTypeIdentifier

  • Afmeldingsårsag - RemovalCauseTypeIdentifierType

Flyttes til

• VisiteringOgStatus.CodeListService

  • Tilmeldekategori

  • Ledighedsgrad

  • Afmeldingsaarsag

VisiteringOgStatus - Tilmeldekategori

Ny kodeliste i VisiteringOgStatus - Tilmeldekategori

VisiteringOgStatus - Ledighedsgrad

Ny kodeliste i VisiteringOgStatus - Ledighedsgrad

Tilsvarende ændringer i DFDG (classic).CodeListService (version 5).CurrentUnemploymentStatusTypeIdentifier

Ledighedsgrad ‘Arbejdsfordeling’ kan som hidtil angives v/tilmelding gennem KSS, men ikke ved borgers tilmelding på Jobnet. Og heller ikke ved a-kassens registrering af tilmelding som jobsøgende.

Ifm. tilmelding anvendes fremover id 2-4. Ifm. sygmelding anvendes som hidtil id 0 og 1.

(DAK har efter drøftelse med a-kasser bekræftet, at vi ifm. tilmelding ikke behøver sondre mellem fuldt og delvist ledig.)

VisiteringOgStatus - Afmeldeaarsag

Ny kodeliste i VisiteringOgStatus - Afmeldeaarsag

1005.17.1.8 - PersonStatusService (version 20) og PersonHistoryService (version 4) udstiller i en overgangsperiode oplysninger om til- og afmelding

PersonStatusService (Version 20)

GetVariablePersonStatus

PersonStatusService (version 20) udstiller i en overgangsperiode indtil 2025-1 oplysninger om til- og afmelding

PersonHistoryService (version 4)

GetPersonHistory

PersonHistoryService (version 4) udstiller i en overgangsperiode indtil 2025-1 oplysninger om til- og afmelding

1005.17.23.9 - Som aftager vil jeg kunne få besked om opdateringer til tilmelding med WSRM eller WSB og kunne hente en unik tilmelding baseret på id

Løsningsmodel

• Eksisterende WSRM’er om tilmelding og afmelding som jobsøgende opretholdes i en overgangsperiode

  • GetUnemploymentEnrollmentVersion4 på WsrmMessageService (version 10) og

  • GetCancelUnemploymentEnrollmentVersion4 på WsrmMessageService (version 10)

• Ny WSB: Tilmelding.wsb

• WSRM om fremtidig afmelding sendes som hidtil på tidspunktet for indberetning af opdateringen. Tilsvarende vil gælde for WSB om afmelding.

Udsendelse af WSRM og WSB som følger:

Ny Tilmelding.wsb

1005.17.1.10 - Død kode i DFDG, i forbindelse med til- og afmelding, fjernes

Løsningsmodel (internt STAR acc.kr.)

• Fjernelse af gammel og død kode i DFDG classic

1005.17.1.11 - Landssupport/LSS er skiftet over til at brug den nye REST-servicen ift. til- og melding , i stedet for UnemploymentEnrollmentService fra DFDG classic

Løsningsmodel (internt STAR acc.kr.)

• Landssupport/LSS er skiftet over til at brug den nye REST-servicen ift. til- og melding , i stedet for UnemploymentEnrollmentService fra DFDG classic

• Kode brugt i forbindelse med UnemploymentEnrollmentService er fjernet fra LSS

1005.17.23.12 - DFDG batchjobs vedr. til- og afmelding flytter til til forretningsdomænet (silo) VisiteringOgStatus

Løsningsmodel (internt STAR acc.kr.)

• DFDG-TASS-CancelEnrollmentForRelevantAbsenceTypes

• DFDG-TASS-CancelEnrollmentLetter

• DFDG-TASS-CancelEnrollmentSalarySubsidiaryEnded

• DFDG-TASS-CloseContactGroup1ForPersonsNotEnrolled

• DFDG-TASS-EndEnrollmentWhenFutureIllnessStarts

• DFDG-TASS-ReenrollWhenIllnessEndsLaterThanToday

• DFDG-TASS-ProcessFutureEnrollments

• DFDG-TASS-RunMTOccurence (skifter tilmelding fra tilmeldekategori ‘dimittend’ til ‘dagpengemodtager’ på dagpengeretsdato , dvs. ved opnåelse af 1 års anciennitet som medlem af a-kasse/a-kasser)

• DFDG-TASS-RunMTOccurenceIllDimittends

Se på TopDesk sag sammen med genimplementering af batchjob;

• S2312-626 Serviceeftersyn af DFDG-TASS-ReenrollWhenIllnessEndsLaterThanToday

1005.17.23.13 - Forfine DFDG-TASS-ProcessFutureEnrollments, når batchjobbet skal flyttes til nyt DFDG forretningsdomæne

Løsningsmodel (internt STAR acc.kr.)

• Hvis borger raskmeldes d.d. og har eller får et andet sygefravær, der er aktivt før DFDG-TASS-ProcessFutureEnrollments kører, skal batchjobbet ikke fejle, men blot springe over at forsøge at raskmelde den pågældende borger (FB 368766).

1005.17.28.14 - Som aftager vil jeg kunne abonere på WSB om Varslinger som afløsning for GetWarning WSRM

WSB Varsling som afløser for GetWarning WSRM. Den udsendes i denne release kun for id’er relaterede til afmelding, dvs. hvor afmeldeårsag refereres i WarningTypeIdentifier

WSB Varsling oprettes:

Tjekliste modernisering DFDG:

• DFDG

  • Services

    • Er pakken af service snittet jf. behov i DFDG, Jobnet, eksterne m.f.

    • Er der behov for at bevare SOAP snitfladen

    • Er dansk navngivning QA'et

    • Er der teknisk gæld eller andet der skal rettes op på (evt. spike til team/arkitekt for at identificerer)

  • Konvertering

    • Initielt load / konvertering og i hvilke siloer

  • WSRM'er
    
    

    • Skal eksisterende WSRM udsendes og hvor længe

    • Skal ny besked etableres nu eller senere

  • Kodelister, er disse flyttet til ejende domæne, er der lavet slavekodelister

  • Eventbroker

    • Er nye beskeder der skal etableres, QA af indehold og navngivning

    • Er det dokumenteret hvilke beskeder, der anvendes, og hvilke forretningsregler der er i den forbindelse

  • StatusService

    • Udfasning i PersonStatusService (PSS) 

    • Udvidelser til domænespecifikke statusservices

    • Udfasning i PersonHistoryService (PHS)

    • Udvidelse til domænespecifikke historik services

  • LSS (Landssupportsystem) og/eller Datakanon og herunder Registerudtræk (hvis STAR har dataejerskab)

  • Datamonitor. ny eller ændret overvågninger

  • Dokumentation

    • QA i forhold til at alle forretningsregler / fejlkode er tilstede

    • Dokumentation følger nye principper

• Nye batchjobs / ændret behandling af events

  • 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.

• Ændringer i forhold til aflevering at Rigsarkivet

• GDPR sletninger m.v.

• Interne afhængigheder indenitfiseret (Jobnet, VITAS, JobAG, BI integrationsplatform andre domæner m.v.)

• Eksterne afhængigheder indenitfiseret (Kommunalt sagsbehandlingssystem, A-kasse sagsbehandlingssystem, Kommunalt bookingsystem (WorkForcePlanner (WFP), M4 Booking, Schultz Booking). Kommunalt ydelsessystem (KY), Kommunalt sygedagpengesystem (KSD), EG kommune informatiom m.fl.)

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:  

BI foretager initial load af forsørgelseshistorik i ydelsesudstilling silo. Der er ikke tale om konvertering i denne forbindelse da det er samme loadmodel som i den gamle forsørgelseshistorik på DFDG classic.

Efter idriftsættelse:

N/A

Arkitektur- og implementeringsnoter 

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

• Nye dataområder: Nej, flytning til domæne Ydelsesudstilling 

• Nye snitflader: Nej, flytning til domæne Ydelsesudstilling

• Nye komponenter: Nej 

• Nye miljøer: Nej 

• Nye teknologier: Modernisering 

• Nye aftagertyper: Nej 

• Eller afvigelser fra principperne: Nej 

• Eventuelle behov for reduktion af teknisk gæld skal afdækkes: N/A 

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.

• Angiv hvem der har foretaget dette tjek: Jesper Brunholm

• Angiv dato for tjek: 17-4-2024

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.

Dette er ikke et nyt dataområde blot en flytning fra DFDG classic og til VisiteringOgStatus 

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

A-kasse filtrering i de nye getmetoder følger a-kasse filtreringen på deres soap-forgængere

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

Der ændres ikke på sagsbehandlerlogin ifm. omlægningen