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

https://starwiki.atlassian.net/browse/BI-2755

https://starwiki.atlassian.net/browse/BI-2878

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.

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

KSD

KOMBIT (KSD) har 17.02.2023 oplyst at CPR-skifte i KSD håndteres således:

KY

Ifm. datagenopretningssager i 2022 er det ift. KY konstateret:

KY har en personid-model hvor alle data er redigerbare på alle CPR for en borger.

Regler

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

Løsningsovervejelser

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.

Nye DFDG forretningsdomæner

865.31.1 - I nye DFDG forretningsdomæner flyttes data (pegepinden til data) til at være borgers aktuelle cpr.nr

I nye DFDG forretningsdomæner flyttes data (pegepinden til data) til at være borgers aktuelle cpr.nr.

865.31.2 - Ved opstart af nye DFDG forretningsdomæner indlæser STAR data fra DFDG (classic) uanset borgers CPR-status (bl.a. af hensyn til aflevering af data til Rigsarkivet) og af hensyn til bl.a. a-kassers behov for at kunne læse historiske data om et medlem)

Alle borgers data samles under nuværende personnummer.

Hvis borger har konfliktende data på nyt og gl. cpr nr, vinder data på det nye cpr nr. Tilsvarende, hvis der er periodeoverlap for data, hvor dette ikke er tilladt, afkortes perioden på det ældste personnummer, så startdato for data på det nyeste/aktuelle kan bevares.

865.31.3 - Serviceaftagere kan hente/læse data i de nye forretningsdomæner uanset om der kaldes med borgers aktuelle eller historisk cpr nr - også hvis borger er død

Serviceaftagere kan hente/læse data i de nye forretningsdomæner uanset om der kaldes med borgers aktuelle eller historisk cpr nr - også hvis borger er død.

865.31.4 - I nye DFDG forretningsdomæner kan der alene registreres og opdateres data ved kald med borgers aktuelle cpr.nr

Ved registreringskald til nye DFDG forretningsdomæner med ikke-aktuelt CPR nummer kaster DFDG (ny) fejlkode med oplysning om at borgers aktuelle cpr nr skal anvendes

Dermed fremgår det klart, om der er tale om en cpr.nr skifter eller et cpr.nr som ikke findes. Fejlkode: XXX1 - “Det er ikke muligt at registrere data på dette personnummer, som ikke er borgers aktuelle”.

865.31.5 - For de allerede opstartede DFDG forretningsdomæner foretages efterkonvertering / indlæsning af data for de CPR-statusser som i første indlæsning blev udeladte, således at databestanden er komplet

For de allerede opstartede DFDG forretningsdomæner foretages efterkonvertering / indlæsning af data for de CPR-statusser som i første indlæsning blev udeladte, således at databestanden bliver komplet.

Dataområder hvor efter-indkonvertering vil skulle ske

• Indkaldelser

• Deltagelsesvalg ifm. indkaldelser

• Afholdte samtaler

•  

Ovenstående liste er under udarbejdelse, og er således ikke komplet

865.31.6 Ved registreringskald til nye DFDG forretningsdomæner med ikke-aktuelt CPR nummer kaster DFDG (ny) fejlkode med oplysning om at borgers aktuelle cpr nr skal anvendes

Ny fejlkode: 9460 - Det er ikke tilladt at registrere oplysninger på borgers ikke-aktuelle personnummer

865.31.7 Der kan (fortsat) trækkes en CreatePersonGuestAccess / CreateGaesteadgang på en borgers gl. CPR-nr.

Der kan (fortsat) trækkes en CreatePersonGuestAccess / CreateGaesteadgang på en borgers gl. CPR-nr.

Aktuel implementering

Der er fire mulige måder, hvorpå en ekstern bruger kan agere for at oprette en gæsteadgang i DFDG. Nedenfor præsenteres hver måde og dens tilsigtede resultat.

Kald til DFDG Classic PersonStatusCommentService (2020-3)

Kald med det aktuelle CPR:

1. DFDG Classic kalder videre til Borgerkommunikation med det aktuelle CPR og opretter gæsteadgang for den kaldende bruger, for det aktuelle CPR.

2. Borgerkommunikation rejser event med det aktuelle CPR.

3. WSRM dannes på borgerens aktuelle CPR.

4. Eventet konsumeres i DFDG Classic. Gæsteadgang oprettes for borgerens aktuelle, og alle tidligere CPR. 

Kald med gammelt CPR:

1. DFDG Classic kalder videre til Borgerkommunikation med det aktuelle CPR og opretter gæsteadgang for den kaldende bruger, for det aktuelle CPR.

2. Borgerkommunikation rejser event med det aktuelle CPR.

3. WSRM dannes på borgerens aktuelle CPR.

4. Eventet konsumeres i DFDG Classic. Gæsteadgang oprettes for borgerens aktuelle, og alle tidligere CPR. 

Kald til Borgerkommunikation Borgerkommunikation.GaesteadgangService (2023-1)

Kald med det aktuelle CPR:

1. Borgerkommunikation rejser event med det aktuelle CPR.

2. WSRM dannes på borgerens aktuelle CPR

3. Eventet konsumeres i DFDG Classic. Gæsteadgang oprettes for borgerens aktuelle, og alle tidligere CPR. 

Kald med gammelt CPR:

1. Borgerkommunikation kaster fejl, hvis borgeren ikke eksisterer

Senere release

Vi ser på muligheden for, at der kan opnås gæsteadgang ved kald af Borgerkommunikation.GaesteadgangService med gl. cpr.nr.

DFDG Classic

865.31.10 - I DFDG (classic) forbliver data på det cpr.nr., hvor registreringen oprindeligt er sket

Der sker ingen flytning af data fra gammelt til nyt personnummer i DFDG Classic

865.31.11 - Fra DFDG (classic) kan data udlæses på det cpr.nr hvor registreringen oprindeligt er sket

Fra DFDG (classic) kan data udlæses på det cpr.nr hvor registreringen oprindeligt er sket

865.31.12 - Det er muligt for aftagerne at opdatere allerede registrerede data i DFDG (classic) ved kald med ikke aktuelt cpr nr fsva data registreret på det pågældende cpr.nr

Det er muligt for aftagerne at opdatere allerede registrerede data i DFDG (classic) ved kald med ikke aktuelt cpr nr fsva data registreret på det pågældende cpr.nr.

865.31.13 - Det er teknisk muligt, men forretningsmæssigt ulovligt at oprette data på gamle personnumre (DFDG validerer ikke herfor)

Det er teknisk muligt, men forretningsmæssigt ulovligt at oprette data på gamle personnumre.

DFDG validerer ikke herfor.

865.31.14 - Ved registrering / opdatering af data med brug af ikke aktuelt cpr nr., dannes afledte WSRM'er / webservicebeskeder på dette ikke-aktuelle cpr.nr

Ved registrering / opdatering af data med brug af ikke aktuelt cpr nr., dannes afledte WSRM'er / webservicebeskeder på dette ikke-aktuelle cpr.nr.

865.31.15 - For SOAP services, som stiller igennem til REST services i en overgangsperiode (såkaldte converters), vil det ikke være muligt at opdatere på gammelt personnummer, da data bor i de nye forretningsdomæner, hvor alene aktuelt cpr nr kan anvendes ved registrering / opdatering

For SOAP services, som stiller igennem til REST services i en overgangsperiode (såkaldte converters), vil det ikke være muligt at opdatere på gammelt personnummer, da data bor i de nye forretningsdomæner, hvor alene aktuelt cpr nr kan anvendes ved registrering / opdatering.

Fælles forhold

865.31.20 - Ved skift af cpr.nr sender DFDG WSRM til alle jobcentre og til egen a-kasse - GetCprChanged

Dette jf. ønske fra KSS ved indledende møde. Der gælder samme forretningsregler som hidtil for udsendelse:

Specielt ift. besked til a-kasser

• Besked dannes for alle, der har et a-kassetilhørsforhold i I DFDG uanset personens aktuelle kontaktgruppe (KG).

• Besked sendes til den a-kasse, der har det aktuelle a-kassemedlemskab iflg. registreringerne i DFDG.

Specielt ift. besked til jobcentre 

• Besked dannes for alle kontaktgrupper i DFDG med følgende modifikationer:

  • Skal kun dannes for tilmeldte personer hvis mindst et af følgende kriterier er opfyldt:

    • Er i kontaktgruppe 1 (dagpengemodtager) og tilmeldt, eller KG1 og sygemeldt

    • Er i KG > 1, tilmeldt og i personkategori 4 (jobparat) eller personkategori 6 (Åbenlyst uddannelsesparat)

    • Er i KG > 1, ikke tilmeldt, har en åben KG og er ikke jobparat eller åbenlyst udd.parat.

• Besked sendes til alle jobcentre

Specielt om elementet PersonCivilRegistrationIdentifierIncidentdate

I en længere periode har denne hændelsedato været udfyldt med 1753-01-01T00:00:00, der er minimumsværdien for DateTime (som anvendes, hvis vi ikke modtager en hændelsesdato fra CPR-systemet).

Fra 2023-3 udfyldes i WSRM-beskeden denne hændelsesdato med det tidspunkt vi modtager hændelsen, da anvendelsen er minimumsværdien giver problemer i nogle aftager-systemer.

865.31.21 - DFDG (domæne) udstiller service/metode som angiver status for et personnummer og tilknytning til evt. Andre personnumre

Så længe borgerstamdata bor i DFDG Classic er en borgers personnummerhistorik tilgængelig i PersonStatusService

Når borgerstamdata flytter til forretningsdomænet Borgerstamdata, vil personnummerhistorikken for en borger blive tilgængelig i PersonStatusService på dette forretningsdomæne.

865.31.22 - Ved cpr.nr. skift som foranlediger aldersskift - herunder batchjobhåndtering

Ift. uddannelsespålæg / plantyper

• Dagpengemodtager o/u 25

• Udd hjælp og overgangsydelsesmodtager med uddannelsespålæg o/u 30

• Kh modt o/u 30

For planer, hvor borger ifm. personnummerskift bliver for gammel til plantypen, inaktiverer DFDG planen, hvorefter en sagsbehandler skal vurdere hvad der videre skal ske.

Ift. kontaktgrupper

Kontaktgruppe som ikke er lovlig fordi borger er blevet for gammel til den vil automatisk blive lukket af DFDGs batchjob (eksisterende funktionalitet: DFDG batchjob, der håndterer at borgere bliver 30 vil natten efter en person er blevet 30 ændre KG fra fx udd.hj.modtager til kth-modtager). Der sendes WSRM på borgers nuværende CPR.

DFDG vil ikke gøre andet end dette ift. kontaktgruppe da man risikerer at komme i karambolage med KY-kommunikation om kontaktgrupper og disses sammenknytning med borger-sager i KSS systemer.

Indikation på forsøgerpligt

• Hvis børn skifter alder o/u 18

Afklaring udestår

865.31.23 - Forhold for specifikke datadomæner

Afklaring udestår, og vil ske ifm. REST-omlægnings-epics for dataområderne:

• Aktiviteter / placeringer (dublettjek svarende til ActivityService)

• Fraværsforhold (bl.a. af hensyn til 225 timers reglen)

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.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

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