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

Automatisk oversigt

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

Beskrivelse af epic

Baggrund

UDKs databehov

I forbindelse med Udbetaling Danmarks (herefter UDKs) administration af Tidlig pension har UDK brug for oplysninger om følgende:

• om ansøger er på efterløn og datoen for eventuel ophør fra efterlønsordningen for, at der ikke udbetales Tidlig Pension med urette.
• om ansøger har været medlem af en a-kassen op til overgangen til Tidlig pension

UDK kan læse disse oplysninger i DFDG ud fra eksisterende indberetninger fra a–kasserne til DFDG.

A-kassernes databehov

Medlemmer, der overgår til Tidlig pension, skal ikke samtidig kunne modtage efterløn. Måneder med Tidlig Pension skal nedskrive medlemmets eventuelle præmieudbetaling. A-kasserne har derfor behov for at modtage oplysninger fra UDK om:

• Overgangsdatoen til Tidlig pension (for at kende det rette tidspunkt at stoppe efterlønnen).

Tidligere efterlønsmodtagere, der er overgået til Tidlig Pension og som vælger at modtage kompensationsydelse, må ikke få tilbagebetalt efterlønsbidrag. For at A-kassen kan hindre tilbagebetaling af efterlønsbidrag er der behov for, at oplysningen om valg af kompensationsydelse bliver delt med a-kassen.

Til brug for dette oprettes ny snitfalde som UDK kan anvende ved indberetning til DFDG - og så DFDG kan sende (ny) WSRM-besked til a-kassen til brug for a-kassens administration af efterløn samt udstille dette i en get-metode hvor a-kassen kan hente.

Regler

Det vil blive indarbejdet i databekendtgørelsen:

• hvilke eksisterende oplysninger indberettet af a-kasserne til DFDG om medlemskab og efterløn, der videregives til UDK
• hvilke oplysninger UDK skal indberette til DFDG - og at de videregives til a-kasserne

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-kasse

Ved modtagelse af WSRM om overgang til Tidlig Pension skal a-kassesystemet registrere udtræden af efterløn dagen før overgang til Tidlig Pension for medlemmer, der er på efterløn og tilpasse præmieudbetalingsystemet til at fradrage 160,33 timers mulig præmieoptælling pr. måned med udbetaling af Tidlig pension.

Ved modtagelse af WSRM om valg af kompensationsydelse skal a-kassesystemet sikre, at der ikke kan tilbagebetales efterlønsbidrag for dette medlem og at medlemmer med tilvalg af kompensationsydelse ikke udsøges til tilbagebetaling af efterlønsbidrag ved overgang til alderspension.

Jobcenter

Jobcenter fagsystemerne påvirkes - bortset fra ændringer i kodelisterne ClientSystemTypeIdentifier og OrganisationTypeIdentifier - ikke.

Kommunale ydelsessystemer

KY og KMD Aktiv påvirkes ikke.

KSD påvirkes - bortset fra ændringer i kodelisterne ClientSystemTypeIdentifier og OrganisationTypeIdentifier - ikke. Og KSD kun i det omfang KSD skifter fra GetIllnessUpdatedVersion6 til GetIllnessUpdatedVersion7, hvor kodelisten ClientSystemTypeIdentifier anvendes.

Danske forretningstermer i DFDG services

991.3.1 - UDK kan indberette oplysninger til DFDG om afgørelser om Tidlig pension og afgørelser om Kompensationsbeløb

SaveTidligPension metoden skal kunne kaldes af myndighedstyperne:

• UDK
• STAR

(Get-metode: Se acc.kr. 991.3.3 nedenfor)

Da det ikke kan afvises at der forekommer afgang fra TidligPension som efterfølges af en ny tilgang til TidligPension, er der medtaget en GUID som er specifik for et "forløb", startende ved mindst 1 afgørelsesdato, og som skal bruges ved opdateringer til samme forløb.

Der valideres imod at to Tidlig Pension forløb på en borger overlapper med hinanden (defineret ved TidligPensionOvergangsdato og TidligPensionOphoersdato). Fejl som kastes i den sammenhæng: 9434 - Forløb må ikke overlappe andet Tidlig Pension forløb.

Der laves en Save-metode som fungerer og bruges som følger:

1. Der laves en første skrivning. Hvis GUID er medsendt anvendes denne, ellers oprettes der en GUID, som fås i response. Der sendes WSRM med Create indikation til WSRM-aftagere. 
2. Efterfølgende kald med samme GUID overskriver fuldstændigt tidligere indberetning(er), så hvis fx PaymentOfRecompense sendes i 1 kald, skal den medsendes i alle efterfølgende kald for fortsat at eksistere på forløbet. Der sendes WSRM med Update indikation til WSRM-aftagere.
3. Efterfølgende kald med samme GUID uden hverken OvergangTilTidligPension eller Kompensationsudbetaling er at betragte som en korrektion (da sletning som sådan ikke giver mening). Der sendes WSRM med Update indikation til WSRM-aftagere.

Bemærk at kun RegistrationType Create og Update er i brug, der kan ikke komme en WSRM af typen Delete.

PensionService (Version 1).SaveTidligPension

Response

Fejl

Fejlkoder med grå baggrund er del af STARs standard Fejlhåndtering som normalt ikke fremgår af snitfladebeskrivelsen

991.3.2 DFDG danner WSRM til a-kasser på baggrund af UDKs indberetning af oplysninger

Ny WSRM-beskedtype på WsrmMessageServicev (version 11).GetTidligPensionVersion1.

Beskeden sendes til borgers aktuelle a-kasse (medlemskab på UDK indberetningstidspunktet er eneste betingelse for afsendelse af WSRM til a-kassen).

Beskeden sendes ved UDKs indberettelse af Tidlig Pension med RegistrationType Create og ved eventuelle opdateringer med RegistrationType Update (dvs. for WSRM aftager fungerer dette helt som det plejer)  

WsrmMessageService (Version 11).GetTidligPensionVersion1

Kodelisten ClientSystemTypeIdentifier opdateres

Kodelisten ClientSystemTypeIdentifier opdateres således at UDK kan fremgå som aktør, der har foranlediget WSRM-besked.

• Id 12 omdøbes, da den pågældende styrelse har ændret navn
• Id 13 omdøbes (da Systematic ikke mere driver serviceplatformen)
• Id 18 beskrivelse opdateres.
• Id 31 påsættes slutdato, da Jobcenter Planner ikke anvendes efter release 2020-4
• Nyt id 57 (Udbetaling Danmark)

Drop-down liste i AmpAdmin2 opdateres (Internt rettet)

Dropdown liste i AmpAdmin2 opdateres således, at den/de nye/ændrede kodelisteværdier i kodelisten ClientSystemTypeIdentifier kan vælges.

Kodelisterne i DFDG, Taxonomy, JobSearch og Ydelsesudstilling for OrganisationTypeIdentifier opdateres

• Id 9 og 10 lukkes, da de pågældende organisationstyper ikke længere findes
• Id 16 omdøbes, da den pågældende styrelse har ændret navn
• Id 19 omdøbes, da det pågældende ministerium har skiftet navn

993.3.3 - Oplysninger som UDK indberetter om afgørelser om Kompensationsbeløb og Tidlig pension skal udstilles i Get-metode.

Metoden skal kunne kaldes af myndighedstyperne:

• A-kasse (for egne medlemmer)
• UDK
• STAR

PensionService (Version 1).GetTidligPension

Input

Output

Fejl

9214 gives i tilfælde hvor der ikke foreligger nogen data på den pågældende borger.

991.3.4 - De oplysninger UDK indberetter kan ses i LSS og indgå i registerudskrift

Oplysninger som UDK indberetter om afgørelser om Kompensationsbeløb og Tidlig pension skal kunne aflæses LSS og indgå i registerudskrift.

991.3.5 - UDK kan læse oplysninger i DFDG om dato for overgang til efterløn og dato for afgang fra efterløn

Oplysninger om dato for overgang til efterløn og evt. afgang fra efterløn kan læses i EarlyRetirementDataService.GetLatestEarlyRetirementData:

Opdatering af adgangsattribut

Metoden opdateres adgangsattributmæssigt således, at UDK som myndighedstype kan kalde metoden.

Efterfølgende tildeles i AmpAdmin2 tillige rettigheder på UDKs certifikat til, at UDK kan kalde servicen/metoden. Tildelingen sker manuelt via AmpAdmin2 (i både test og i prod., da det kun er ét certifikat, der skal have opdateret rettigheder i test og prod.).

991.3.6 - UDK kan læse oplysninger i DFDG om de seneste 9-12 måneders medlemskab af a-kasser

Historik for medlemskab af a-kasser udstilles i UnemploymentFundMembershipService (Version 4) .GetMembershipHistory (som jf. STARs arkitektur roadmap på sigt skal overtage opgaven fra PersonHistoryService.GetPersonHistory - kollektionen UnemploymentFundCollection).

Hvis UnemploymentFundMemeberShipIsRecalled = true er den pågældende medlemsperiode annulleret / ikke gældende.

UDK vil selv skulle frasortere den del af medlemshistorikken, der ikke skal anvendes.

UnemploymentFundMembershipService (Version 4).GetMembershipHistory

Adgang til metoden:

A-kasser, Jobcentre, Kommuner og Anden Aktør kan tilgå metoden på egne borgere samt efter reglerne om gæsteadgang. A-kasser har derudover adgang til tidligere borgere efter samme regler som i /wiki/spaces/GI/pages/2356183177.

UDK og STAR kan tilgå metoden på alle borgere.

Rækker af særlig interesse for UDK er fremhævede.

Adgangsattribut

Metoden dekoreres adgangsattributmæssigt således, at UDK som myndighedstype kan kalde metoden (efterfølgende tildeles i AmpAdmin2 tillige rettigheder på UDKs certifikat til, at UDK kan kalde servicen/metoden). Tildeles manuelt i både test og i prod., da det kun er ét certifikat, der skal have opdateret rettigheder i test og prod.).

991.3.8 DFDG GDPR-sletter oplysninger om TP og Kompensationsbeløb 6 år efter folkepensionsalder

DFDG sletter oplysninger om TP og Kompensationsbeløb 6 år efter folkepensionsalder. Der sendes ikke GDPR-slettebesked herom til a-kasserne.

Folkepensionsalder for personer født efter 1970 er endnu ikke fastsat af Folketinget.

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: Ja, der oprettes et nyt dataområde, Tidlig Pension 
• Nye snitflader:  Der laves en ny service, med et Save pattern som ikke bruges ofte (men er kendt fra fx UnemploymentFundPaymentService)
• Nye komponenter:  Nej
• Nye miljøer:  Nej
• Nye teknologier:  Nej
• Nye aftagertyper:  UDK er ny aftager ift. at skulle levere data
• Eller afvigelser fra principperne:  Nej
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes:  Opdatering af kodelister for OrganisationTypeIdentifier og ClientSystemTypeIdentifier

STARs arkitekturforum er repræsenteret i epic'ens udarbejdelse.

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: 2021-05-19

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.  

Der er for hver metode taget stilling til adgang til data.

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.

Der er a-kasse-filtrering på de udstillede data i samme tilstrækkelige omfang som hidtil.

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

Data udstilles ikke på Jobnet