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)

DS-8598 - Getting issue details... STATUS

BI-1696 - Getting issue details... STATUS

JOB-5724 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

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.

Bemærk at der i ISB 999 er lavet en oversigt over løsningens indhold i forskellige releases, som også er indsat nedenfor for øget overblik ifm. gentilsagn. 

Automatisk oversigt

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

Beskrivelse af epic

Baggrund

Regeringen, Dansk Folkeparti, Socialistisk Folkeparti og Enhedslisten er enige om, at beskæftigelsesindsatsen skal nytænkes, så jobcentrene bruger ressourcerne der, hvor de har størst effekt og kommer flest ledige til gavn.

Delaftalen fremgår på bm.dk. Link til aftalen: 2021-juni-aftaletekst_foerste-delaftale-om-nytaenkning-af-beskaeftigelsesindsatsen.pdf.

Elementer i aftalen

Aftalen indeholder følgende elementer (her alene gengivet kort, idet der i øvrigt henvises til aftaleteksten):

• En styrket og forenklet ungeindsats
  • Færre proceskrav for indsatsen til uddannelseshjælpsmodtagere
    • Aftalepartierne er enige om, at lempe og forenkle kravene til uddannelseshjælpsmodtageres deltagelse i intensiv, kontinuerlig aktivering, så der fremover må være fire måneder mellem hvert tilbud.
    • Forslaget ændrer ikke ved kontaktforløbet (samtaler) med de unge. Det fastholdes desuden, at unge skal have deres første samtale i jobcenteret inden for én uge efter første henvendelse til kommunen og skal have første tilbud inden for første måned.
  • Styrket understøttelse af overgang til og gennemførelse af uddannelse
    • Uddannelseshjælpsmodtagere der påbegynder en uddannelse får ret til en mentor, der kan understøtte, at den unge fastholdes i uddannelsen. Retten til en mentor gælder i op til 6 måneder efter uddannelsesstart med mulighed for forlængelse
    • Jobcenteret forpligtes til at reagere på beskeder om risiko for frafald fra uddannelsesinstitutionerne de første 6 måneder efter studiestart. De kan herefter tage stilling til, om relevante fastholdelsesinitiativer skal iværksættes.
• Samtaler over video eller telefon
  • Aftalepartierne er ... enige om, at borgerne skal have større fleksibilitet og mulighed for selv at vælge mødeformen ved en samtale.
    Med denne aftale får ledige efter seks måneders ledighed mulighed for at vælge, om samtaler med jobcenter eller a-kasse skal afholdes ved personligt fremmøde, over video eller telefonisk.
  • Jobcenter og a-kasse kan ændre samtaleformen fra video eller telefonisk til personligt fremmøde, såfremt de vurderer, at der er behov for det.

Regler

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

I de almindelige bemærkninger i lovforslag L 67 fremgår bl.a.:

Partierne bag Første delaftale om nytænkning af beskæftigelsesindsatsen (S, DF, SF, EL), forligskredsen bag beskæftigelsesreformen (S, DF, V, RV, K) samt forligskredsen bag sygedagpengereformen (S, V, RV, SF, DF, K og LA) er i februar 2022 orienteret om, at implementeringen vil være lidt mere tidskrævende end først antaget - og bliver forsinket med tre måneder, fra juni 2022 til september 2022.

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.

A-kasser, KSS og Planner-systemer vil skulle omlægge til nogle nye services, jf. afsnittet "Oversigt over berørte webservices".

Overblik over services som er tilgængelige i 2022-3 og 2022-4. Skemaet er forældet pr. udsendelse af epic 999.5 til tilsagn og er derfor fjernet. Se i stedet det tværgående skema i ISB 999

Forretningsmæssige flows imellem BookingService og IndkaldelseService

Hovedflow

Indkaldelse oprettes med IndkaldelseService.CreateIndkaldelse, hvilket foranlediger WSRM'erne GetIndkaldelseVersion1og GetAkasseIndkaldelseVersion1 fra WSRMMessageService V11, samt BookingWSRMMessageService.GetBookings. 

Hvis der er tale om en indkaldelse til fælles jobsamtale med dagpengemodtager (samtaletype id 17) forventes den indkaldte myndighed at "besvare" indkaldelsen ved at opdatere den myndighedsdeltager, der er angivet på indkaldelsen med IndkaldelseService.UpdateMyndighedsdeltager. Dette gør at de samme 4 WSRM'er sendes til eksterne aftagere. DFDG udfylder InterviewWithMoreAuthorities baseret på samtaletypen.

Indkaldelsen kan hentes ud med IndkaldelseService.GetIndkaldelse. Historik på indkaldelsen kan hentes med IndkaldelseService.GetIndkaldelseshistorik

Workaround-flow / nødflow der kan anvendes af eksterne aftagere aht. at nå i mål med 2022-3

Indkaldelsen oprettes med BookingService (Version 2).CreateBooking hvilket foranlediger WSRM'er som i hovedflow. DFDG kalder CreateIndkaldelse pba. CreateBooking. GruppemoedeEjersystem sættes ikke.

Hvis der er tale om en indkaldelse til fælles jobsamtale med dagpengemodtager (samtaletype id 17) er BookingParticipantCollection (jf. gældende valideringer siden 2019-4) udfyldt med en myndighedsdeltager som vil ligge til grund for at DFDG opretter indkaldelsen med IndkaldelseService. 

Indkaldte myndighed kan stadig "besvare" indkaldelsen ved at opdatere den myndighedsdeltager der er angivet på indkaldelsen med IndkaldelseService.UpdateMyndighedsdeltager og indkalder notificeres om denne besvarelse med WSRM, samt kan hente den med GetIndkaldelse.

Indkaldelsen kan hentes ud som i hovedflow.

Acc.kr. 999.3.1 - Som borger vil jeg på Jobnet kunne tilgå link til digitalt møde indkaldt af jobcentret

Når borger har et kommende møde med samtaleform 8 - Digitalt møde - vises link til dette som en del af borgerens oplysninger om mødet på Jobnet. Dette løses i Jobnet i følgende story: JOB-6580 - Getting issue details... STATUS

Acc.kr. 999.3.2 - Som borger vil jeg kunne vælge samtaleform, når jeg booker på Jobnet

Modernisering af InterviewContactTypeIdentifier, som bliver til kodelisten SamtaleformType

Kodelisten hedder SamtaleformType i nye services i kontaktforløbs-siloen, og hedder fortsat InterviewContactTypeIdentifier i DFDG classic (incl. WSRM'er). Indholdet bliver ens i de to kodelister:

Id 4 udgår, fordi vi ønsker at id 8 ensrettet bruges til videomøderne

Id 5 udgår, fordi vi ikke ser et forretningsmæssigt formål, og vi er nervøse for, at det er en "skraldespand" hvis indhold burde være delt ud på øvrige registreringer.

Id 9 indføres for, at det fortsat er muligt at registrere afholdte samtaler, hvor kontakt er sket igennem 3. person. Dette for understøttelse af Sygedagpengeloven §13, stk. 5

Jobnetfunktionalitet

Jobnetfunktionaliteten udvikles i Valg af samtaleform ved selvbooking. Bemærk, at der er en en smule ændring til teksterne, der vises i jobnet. Der vises følgende på Jobnet: 

BookingService bliver til IndkaldelseService (men BookingService forbliver tilgængelig i 2022-3)

Swagger til IndkaldelseService T3 - bemærk at servicen er tilgængelig men ikke færdigtestet: https://kontaktforloebt3.startest.dk/swagger/index.html?urls.primaryName=Indkaldelse%20V1

Servicestrukturen er tilgængelig på 999... IndkaldelseService (Version 1) (tidl. BookingService).

DigitaltMoedelink skal være til stede, når mødet er med afholdelsesform id 8 "Digitalt møde", og vises da for borger på Jobnet. Ved andre afholdelsesformer vises feltets indhold ikke for borger. Samme link forventes at kunne bruges til gæstende myndigheders deltagelse i møder, fx fælles jobsamtale, uanset om borger deltager fysisk. Af hensyn til sammenhæng imellem at få indkaldelser indrapporterede gennem BookingService og IndkaldelseService bevares feltet Kontaktdetaljer (ContactDetails) i Myndighedsdeltagere (med 1-256 tegn, da det var dette der de facto var understøttet).

Feltet selvbooket vil fremadrettet fungere sådan, at når borger 1 gang aktivt har booket eller ombooket på en indkaldelse, så forbliver feltet TRUE i resten af indkaldelsens forløb (og det vil være ulovligt at opdatere feltet til FALSE).

UpdateIndkaldelse

Myndighedsdeltagere er en del af metoden for at understøtte eksisterende forretningsflow. Det er kun den oprindeligt oprettende myndighed der må bruge metoden, og det indsendte overskriver hele det eksisterende objekt (svarende til funktionaliteten i BookingService).

Beskyttelse af gruppemøder med validering

Som en del af indkaldelsestrukturen tilføjes 2 nye felter: GruppemoedeId og GruppemoedeEjersystem. Når GruppemoedeEjersystem er sat, validerer DFDG imod at gruppemødet kan ændres af andre systemer.

Kan ses på 999... IndkaldelseService (Version 1) (tidl. BookingService)

Fælles jobsamtale med gæstende myndighed forenkles

Struktur indlagt på 999... IndkaldelseService (Version 1) (tidl. BookingService)

InterviewWithMoreAuthorities og myndighedsdeltagelse (InterviewUnemploymentFundParticipation) forenkles til at indkalde myndigheden (altså at der i Myndighedsdeltagere er en myndighedsdeltager af den myndighedstype som gæstende myndighed er). Mødeaccept fra gæstende myndighed giver klar kommunikation. Separat opdatering af myndighedsdeltagere med GUID gør registrering enkel (man skal ikke håndtere hele mødet).

EksternIdentifikation og mødeaccept samt kontaktinfo giver smidigere kontakt. Indikation om frasagt deltagelse på indkaldelsen gør, at aktuel information er samlet på et sted.

Man skal opdatere eksisterende myndighedsdeltager med accept/afvisning af deltagelse inden man påfører en ny, fejl: 90101 - "Opdater eksisterende myndighedsdeltagere inden oprettelse af nye". Dette gælder også ved oprettelse, hvor man kun kan tilføje en myndighedsdeltager af en given type uden at forholde sig til deltagelsen.

Floweksempel

1. Ved indkaldelse til fælles jobsamtale med dagpengemodtager i a-kasse-forsøg oprettes en myndighedsdeltager af typen jobcenter. Dermed er det indikeret, at jobcentret forventes at deltage
   
2. Jobcentret går efterfølgende ind og accepterer mødet og bekræfter dermed sin deltagelse samt tilføjer kontaktinformation.
3. Mødeaccept fra myndighed giver klar forventningsafstemning imellem myndighederne
4. Deltagelsesvalg håndteres fortsat uafhængigt af indkaldelser i egen metode, men sættes ind på indkaldelsen for at have sammenhængende information

A-kasserne får adgang til ombooknings- og aflysningsindstillinger

A-kasserne har for enkelhedens skyld hidtil ikke haft adgang til anvendelse af felterne for, om borger må kunne ombooke og aflyse et møde, samt deadlines for dette.

Det laver vi om på, da der er fremsat ønske om, at a-kasserne også vil have mulighed for at vælge at udnytte informationerne, som koordinerer, hvad borger må, imellem en a-kasses indkaldesystem og en a-kasses selvbookingsystem.

1. ReBookingPossible og ReBookingDeadline bliver OmbookningMulig og Ombookningsfrist
2. CancellationPossible og CancellationDeadline bliver til Aflysbart og Aflysningsfrist

Valideringerne forbliver de samme som hidtil, hvor frist kun kan sættes, hvis hovedattributten er sat (fx kun aflysningsfrist, når aflysbart er true).

Adressebekendtgørelsesoverholdelse

Bekendtgørelse om vejnavne og adresser siger bl.a. i Kapitel 5, §16, om husnumre, at

“Stk. 2. Et husnummer består af indtil 4 tegn. Et husnummer består altid af et tal i intervallet fra 1 til 999, som eventuelt kan være suppleret af ét stort bogstav fra A til Z, uden mellemrum mellem tal og bogstav. Et eventuelt bogstav er en del af husnummeret. Husnumre med og uden bogstav er ligestillede. På grund af risikoen for forveksling må bogstaverne I, J, O og Q dog ikke benyttes i et nyt husnummer, eller når et husnummer ændres.”

Vi har dog det problem, som indlagt i fx FB 246713 at vi får data fra CPR registeret, som ikke overholder dette format.

Løsningsmodellen bliver regex-baseret.

Data fra CPR vaskes ifm. import, således at de overholder standarden.

Registrering af mødedeltagelsesvalg

Metoderne fra PersonRegistrationService til registrering af gæstende myndigheds deltagelsesvalg i fælles jobsamtale, samt registrering af borgers valg om gæstende myndigheds deltagelse, flytter til IndkaldelseService men kan fortsat benyttes i PersonRegistrationService i 2022-3.

Metoden, SaveDeltagelsesvalg, er beskrevet på underside.

Hvis et sådant valg indkommer imens der ligger en åben indkaldelse på myndighedens deltagelse, fjernes myndigheden fra denne indkaldelse. 

Hvis registrering foretages, imens der foreligger en indkaldelse, påføres valget, og myndighedens deltagelse fjernes, hvis der er tale om fravalg, hvis der er tale om tilvalg forventes myndigheden selv at opdatere indkaldelsen med accept af mødet og deltagelse. WSRM IndkaldelseOpdateret udsendes til relevante parter. 

Som hidtil:

Når DFDG modtager registreringen sendes WSRM (WSRMMessageService v10.GetMeetingParticipation) om dette til såvel a-kasse som jobcenter.

Hvis den gæstende myndighed fravælger at deltage, opdateres en eventuel allerede oprettet indkaldelse til et møde af typen ”Fælles Jobsamtale med dagpengemodtager” ved at fjerne den gæstende myndigheds deltagelse. I den forbindelse bliver der, ud over de to WSRM'er om ændret deltagelsesvalg og ændret booking, også sendt en GetWarningVersion4 WSRM til Jobcenteret med WarningTypeIdentifier 51 - "A-kasse-deltagelse fjernet fra booking", medmindre borgeren er a-kasse forsøgs-deltager.

Hvis borgeren fravælger den gæstende myndigheds deltagelse, opdateres en fremtidig indkaldelse til et møde af typen ”Fælles Jobsamtale med dagpengemodtager” ved at fjerne den gæstende myndigheds deltagelse. I den forbindelse bliver der, ud over WSRM'er om ændret deltagelsesvalg (WSRMMessageService v10.GetMeetingParticipation) til begge myndigheder, og ændret booking, også sendt en GetWarningVersion4 WSRM til Jobcenteret med WarningTypeIdentifier 51 - "A-kasse-deltagelse fjernet fra booking" medmindre borgeren er a-kasse forsøgs-deltager.

Der er ingen valideringer på sammenhængene.

Udfasning af BookingInfo fra PersonStatusService

Ny metode GetIndkaldelse på IndkaldelseService overtager status-ansvaret på indkaldelser. PersonStatusService-kollektionen vil returnere blankt.

Udfasning af BookingHistorik og MeetingParticipationHistory på PersonHistoryService

Nye metoder GetIndkaldelseshistorik og Deltagelsesvalgshistorik på IndkaldelseService overtager denne opgave.

2 nye WSRM'er og en opdateret i WSRMMessageService

GetBookings bliver til GetIndkaldelseVersion1 med en struktur som får opdateringerne til indkaldelsesstrukturen, men i øvrigt tilstræbes at ligge så tæt på den nuværende struktur som muligt.

GetBookingsAccepted og GetCancelledBookings samles i GetIndkaldelseshaendelseVersion1. Strukturen er tilgængelig på 999... WsrmMessageService (Version 11, 2022-3)

GetUnemploymentFundBookingVersion1 bliver til GetAkasseIndkaldelseVersion1 med en struktur som får opdateringerne til indkaldelsesstrukturen, men i øvrigt tilstræbes at ligge så tæt på den nuværende struktur som muligt.

BookingWsrmMessageService nedlægges og de nye beskedtyper vil indgå i WsrmMessageService (version 11).

Acc.kr. 999.3.3 - Som borger vil jeg kunne se min seneste Indkaldelse

Borgerens møde for samme dag vises fremover på Jobnet 2 timer efter mødestart, med henblik på at information om mødet også er tilgængelige efter mødestart (i dag vises de ikke så snart mødetidspunktet (klokkeslæt) er nået).

Ovenstående funktionalitet implementeres på forsiden samt under borgers kommende møder.

Årsagen til ikke at benytte mødeafslutningstidspunkt er, at denne ikke er påkrævet i snitfladen. Funktionaliteten realiseres i følgende stories: JOB-7279 - Getting issue details... STATUS og JOB-6580 - Getting issue details... STATUS .

Borgers accept af booking - se teknikaliteterne på Borgers accept af booking - hvornår skal borger acceptere? på underside (kun tilgængeligt internt).

Acc.kr. 999.3.4 - Som STAR vil jeg undgå replikering af kernedata indenfor et forretningsdomæne for at sikre datakvaliteten

Centrale data for indkaldelser flyttes fra DFDG Classic og PersonStatusService datalag til kontaktforløbsforretningsdomænet med den nye indkaldelseservice

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: Jesper Brunholm

• Angiv dato for tjek: 22-04-2022

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