Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Dette indhold kan ikke ses af eksterne (og er ikke relevant for eksterne)

DS-2340 - Getting issue details... STATUS DS-5295 - Getting issue details... STATUS

BI-546 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

(*) GetDeletedSynchronizationEventVersion1 er fra release 2018-2, men har ikke været anvendt i prod.

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 af tabellen.

Automatisk oversigt

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

Beskrivelse af epic

Data for afdøde skal slettes når formålet med at gemme disse ophører. For DFDG ser vi nedenstående 5 primære formål, hvor afleveringen til Rigsarkivet sammen med dokumentation af udbetalingsgrundlaget for ydelser er de længst bestående.

Retlig analyse:
Der findes ingen særlovgivning, hvori det stilles som krav, at jobcenter eller a-kasse skal anvende data om afdøde. Formålet med behandlingen af data ophører derfor ved dødens indtræden, jf. dog ovenfor.

Afleveringspligt til Rigsarkivet (tidligere Statens Arkiver)
Der slettes ikke data om afdøde straks ved modtagelse af oplysninger herom fra CPR registeret. Oplysninger slettes først, når de pågældende data er afleveret til Rigsarkivet, hvis konkrete dataområde er omfattet af afleveringspligten

Administrative hensyn
Ikke relevant, da det afhænger af de konkrete dataområder og dennes generelle slettefrist

Sammenhæng til andre behandlingsaktiviteter
Data anvendes ikke i andre sammenhænge, da formålet er ophørt efter pågældendes død, jf. dog ovenfor.

Det har været overvejet om muligheden for at udregne herkomst for en borgers børn er et formål som spiller ind. Det er afklaret at BI udregner herkomst og sætter deres døde-slettefrist i henhold til dette behov.

Borgere som på tidspunktet for sletning har en profilafklaring bliver sprunget over i sletningen, da denne profilafklaring vil være af typen Min Situation/Rehab (øvrige profilaklaringer slettes efter 4 år), som jf. formål skal opbevares i 10 år. Når profilafklaringsresultatet slettes vil døde-sletningen automatisk blive effektueret.

856.5.1 - DFDG sletter oplysninger om personer afgået ved døden, jf. afgrænsning

Alle data for en borger slettes, incl. stamdata om myndighedstilknytning m.m. 6 år efter at DFDG har fået besked om at borgeren er død.

856.5.2 - DFDG sender slette-WSRM'er til KSS og a-kasser

Den eksisterende besked GetDeletedSynchronizationEventVersion1 (WSRMMessageService v11) sendes med ny kodelisteværdi: 18 - Afdød borgers data (kodelisten DeletedSynchronizationEvent).

Beskeden sendes når sletningen er udført, og til såvel seneste som tidligere a-kasser og jobcentre. Der sendes kun 1 WSRM pr. borger og DeletedIdentifier GUID'en vil være en NULL-GUID. 

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

• DFDG
  • Services
  • WSRMer
  • Kodelister
  • PersonStatusService (PSS)
  • PersonHistoryService (PHS)
  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
• Jobnet
• VITAS
• JobKon
• JobAG
• BI integrationsplatform
• Alle områder
  • Nye batchjobs
    • 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.
• Kommunalt sagsbehandlingssystem
• A-kasse sagsbehandlingssystem
• Kommunalt bookingsystem
  • JobcenterPlanner (JCP)
  • WorkForcePlanner (WFP)
• Kommunalt ydelsessystem

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.