Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Page Properties | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Dette indhold kan ikke ses af eksterne (og er ikke relevant for eksterne)
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Indholdsfortegnelse
Table of Contents | ||
---|---|---|
|
Afgrænsning af epic
Afgrænsning | |||||
---|---|---|---|---|---|
Som STAR vil jeg opfylde mine forpligtelser som myndighed i forhold til GDPR og dermed slette data når formålet med behandling og opbevaring af data ikke længere er tilstede | |||||
Acceptkriterier | |||||
Nr. | Beskrivelse | Relevant for | |||
956856.6.1 | Som STAR ønsker jeg at resultatet af profilafklaring slettes 6 måneder efter at borger har udfyldt forberedelsesskemaet på Jobnet | DFDG, BI | 956.6.2 | Som STAR ønsker jeg at kortdata relateret til joblog slettes 4 år efter at de senest er opdateredeDFDG, BI | |
956.6.3 | Som STAR ønsker jeg at sms- og notifikationsdata slettes 1 år efter afsendelse | DFDG, BI | |||
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||||
---|---|---|---|---|---|---|---|
Acceptkriterie 956Acceptkriterie 856.6.1 | Acceptkriterie 956.6.2 | Acceptkriterie 956.6.3Acceptkriterie | Acceptkriterie | Acceptkriterie <nr.> | |||
A-kasser og KSS systemer skal bekræfte at de ikke har behov for WSRM om sletning af data | XX | X | |||||
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne
(linksLinks i listen virker kun med STAR Jira
konto):konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår af tabellen.
Summary | Varslingstype | Varslingsnote | Eksterne Snitflader | Interne Snitflader | Project |
---|---|---|---|---|---|
Der forventes ingen ændringer til servicesnitflader ifm. denne epic
Automatisk oversigt
(vi arbejder på løsning på at gøre den synlig)Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Beskrivelse af epic
Det altovervejende formål med en borgers data som registreres i Det fælles it-baserede datagrundlag (DFDG) er at medvirke til at sikre borgeren de rettigheder, som borgeren har efter lovgivningen på beskæftigelsesområdet (fremover kaldet borgerens rettigheder). Det understøtter borgerens retssikkerhed.
En borger har ifølge databeskyttelsesforordningen ret til at få sine data slettet uden unødig forsinkelse, når formålet med behandlingen af data ikke længere er aktuelt. Det gælder også personoplysninger i DFDG, hvor STAR er dataansvarlig for de centrale aktiviteter, herunder opbevaringen af de data, som registreres og indberettes via kommunernes og a-kassernes sagsbehandlingssystemer, via Jobnet og eksterne platforme.
For at få afklaringen på hvornår et formål med data ophører har STAR udarbejdet følgende 3 principper:
Princip 1: STAR har lovhjemmel til at indhente og opbevare data om borgere, der er med til at sikre borgernes rettigheder og pligter ift. til:
- Ydelser
- Den beskæftigelsesindsats som er beskrevet i LAB, LAS, sygedagpengeloven, kompensationsloven og integrationsloven mv. for deres målgruppe.
- For at tjene borgerne, skal sagsbehandlere kunne udføre deres arbejde og STAR skal kunne kontrollere, at reglerne følges.
Princip 2: Borgere skal altid have en koordineret og sammenhængende indsats. Det kræver, at oplysninger, der indgår i samme kontekst kan tilgås i sin helhed.
Gælder også når:
- Borgere gennemgår forløb, som bliver længere end gennemsnittet
- Borger evt. skifter målgruppe undervejs
Princip 3: Borgere skal tilbydes en moderne og tidsvarende selvbetjening:
- Ingen genregistreringer af oplysninger, som det offentlige har lovhjemmel til at dele på tværs.
- Borgere skal opleve, at indholdet på STAR's digitale løsninger er tilpasset deres individuelle behov og situation. (Kan indbefatte metadata og data, der er sammenkoblet af forskellige data)
- Borgere skal også selv kunne foretage indstillinger og give accept af fx cookies eller andre former for accepter, som STAR opbevarer.
Som dataansvarlig for DFDG har STAR pligt til at slette oplysningerne, når de ikke længere er aktuelle.
Denne epic vil derfor være den første af en række Epic som er vil være med til at understøtte dette.
For hver dataområdet har styrelsen foretaget en analyse, hvor der er taget stilling til følgende, som dokumenteres anden sted:
- Beskrivelse af databehandlingsaktiviteten samt hvornår dataområdet er indført
- Retlig analyse, herunder om der kan opstå behov for data, fx for at påvise ret til en ydelse
- Stillingtagen til evt. afleveringspligt til Rigsarkivet
- Administrative hensyn
- Dokumentation i forhold til sagsbehandling
- Hensyn til dataminimering
- Klagehensyn
- Genoptagelseshensyn
- Evt. sammenhæng til øvrige behandlingsaktiviteter
- Evt. sammenhæng DSDW
Udsendelse af WSRM til dataaftagere
Som udgangspunkt sendes der kun WSRM på dataområder hvor der for dataaftagerne er hårde bindinger imellem data, som gør at det er nødvendigt at kende DFDGs sletningstidspunkt for at kunne slette data man som databehandler selv er ansvarlig for.
956Overordnede principper gældende for slette-epics fra 2020 er samlede i ISB 856.
856.6.1 Som STAR ønsker jeg at resultatet af profilafklaring slettes 6 måneder efter at borger har udfyldt forberedelsesskemaet på Jobnet
Der afgrænses til profilafklaringsdata for nedenstående profilafklaringsmålgrupper (ScreeningTargetGroup):
1 - Borgere Under 30 (Uddannelseshjælpsmodtagere)
2 - Borgere Over 30 (Kontanthjælpsansøgere over 30 år)
3 - Dagpengemodtagere
Afgrænsningen udelukker profilafklaringsresultater for rehabiliteringsborgere idet formål og slettefrist for denne gruppe ikke er endeligt afklaret.
Der er en forretningsmæssig afklaring omkring gruppe 1 - borgere under 30, hvor der på grund af en tidligere fejl i systemet skal afklares om vi er nødt til at
Værktøjets formål er at hjælpe sagsbehandleren med at vurdere nylediges risiko for at blive langtidsledige på tidspunktet mellem ledighedstilmelding og den første samtale i a-kasse og/eller jobcenteret. Langtidsledighed er i værktøjet defineret som + 6 måneders ledighed. Efter 6 måneder har risikovurderingen enten vist sig at være korrekt eller forkert og oplysningen om risiko vs. ikke-risiko er derfor ikke længere relevant for sagsbehandlingen.
Relevansen af de ti spørgsmål som borgeren har besvaret om sig selv og sine forventninger til sin jobsøgning ved ledighedstilmeldingen, må ligeledes antages at være forældede efter 6 måneder. Slettefristen for oplysninger, som behandles og lagres som led i brug af profilafklaringsværktøjet i DFDG, sættes derfor til 6 måneder efter, at borgeren har udfyldt forberedelsesskemaet på Jobnet.
Sletningen af oplysningerne i DFDG indebærer ikke, at oplysningerne automatisk slettes i DSDW. Oplysningerne vil derfor fortsat kunne anvendes til statistisk opfølgning i det omfang, der er behov for dette i VOA, som selv tager hånd om sletning i DSDW når det er aktuelt.
Sletningens omfang
Sletningen vil omfatte profilafklaringsresultatet med tilhørende data. Snitfladeillustration af dette er jf. ScreeningService (Version 4, 2020-1) at data for GetScreeningResult og GetScreeningResultAsPdf fjernes for de screeninger som slettes.
956.6.2 Som STAR ønsker jeg at kortdata relateret til joblog slettes 4 år efter at de senest er opdaterede
Det længst bevaringsværdige formål med data er tilsyn med myndighedens opgavevaretagelse. Der er ikke fastsat specifikke regler om, hvor længe STAR skal opbevare data om udbetaling af dagpenge mv. bl.a. til brug for opfyldelsen af tilsynsforpligtelsen. Det må derfor følge de almindelige forældelses- og GDPR regler.
Data vedr. rådighed i joblog mv. vil styrelsen længst have behov for i 3-4 år, idet rådighed ofte baserer sig på en samlet skønsmæssig vurdering af en række forhold.
STAR implementerer der for en generel slettefrist på 4 år for kortdata i jobloggen i sammenhæng med oploadede dokumenter i jobloggen. Metadata skal gemmes længere tid pga. afleveringspligten til Rigsarkivet.
956.6.3 Som STAR ønsker jeg at sms- og notifikationsdata slettes 1 år efter afsendelse
STARs udsendelse af SMS’er og notifikationer beror ikke på lovfastsatte forpligtelser hertil, men er en service i forhold til de borgere, der har tilmeldt sig modtagelse af SMS’er og e-mail-notifikationer.
Dataområdet benyttes ikke i en anden behandlingsaktivitet, hvorfor slettefristen fastsættes efter ophøret af formålet med data i forbindelse med tilsyn med myndigheden opgavevaretagelse.
STAR implementerer derfor en generel slettefrist på 1 år for SMS og notifikationerDer afgrænses til profilafklaringsdata for nedenstående profilafklaringsmålgrupper (ScreeningTargetGroup):
1 - Borgere Under 30
2 - Borgere Over 30
3 - Dagpengemodtagere
Afgrænsningen udelukker profilafklaringsresultater for rehabiliteringsborgere idet formål og slettefrist for denne gruppe ikke er endeligt afklaret.
Sletningen sker også hvis der er tale om et delvist resultat, i form af en ufuldstændig udfyldelse af forberedelsesskemaet.
Sletningen sker 6 måneder efter at screeningsresultatet foreligger - CreatedDate i fx GetScreeningResult.
Sletningen er komplet for den enkelte screening, identificeret ved ScreeningResultIdentifier, og omfatter profilafklaringsresultatet med tilhørende data. Snitfladeillustration af dette er jf. /wiki/spaces/GI/pages/2398158930 at data for GetScreeningResult og GetScreeningResultAsPdf fjernes for de screeninger som slettes.
Særlige krav til test
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
* 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.