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

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Beskrivelse af epic

Denne epic er en fortsættelse af arbejdet i 935.3 LAB - A-kasse forsøg 

Bemærk: Jobnet userstory job-151 omhandlende acceptkriterie 935.3.5 (visning af at borgers forløb varetages i a-kasse) først er leveret med 2019-2, da opgaven ikke blev nået i 2019-1 i 935.3. Beskrivelsen ligger dog fortsat i 935.3, da det er den rette kontekst for forståelsen.

Samtaleafholdelse med borger og registreringen af den afholdte samtale med henblik på en klar fælles forståelse af det fælles kontaktforløb

Der indføres en ny, forsøgsspecifik samtaletype: "A-kasse forsøgssamtale". For borgere i forsøget skal alle samtaler indberettes under samtaletypen "A-kasse forsøgssamtale" (id 20) og der tilføjes en ekstra dimension, hvor a-kassen på den afholdte samtale angiver formålet med samtalen (cv, rådighed, jobsamtale). 

Samtaletypen er tilgængelig for alle a-kasser og jobcentre, men der indføres validering så "A-kasse forsøgssamtale" kun kan bookes for borgere omfattet af forsøget og der tilsvarende kun kan registreres afholdt samtale på forsøgsomfattede borgere. .

Sammenhold af samtaleindsats i jobcenteret og a-kassen kan ske ved at anvende samtaletype ”Jobsamtale” for ledige i jobcenteret og samtaletypen "A-kasse forsøgssamtale". Der kan kun afholdes 1 samtale af denne type pr dag.

A-kassen skal derudover kunne indkalde, afholde og registrere såvel jobsamtale registrere Fællessamtale med dagpengemodtager (InterviewType id 7) som Fælles Jobsamtale 19). ¤Afklaring: men ikke længere jobsamtale (InterviewType id 197).

A-kassen opretter indkaldelser med BookingService hvor der generelt (¤Afklaring: eller kun for forløbsdeltagere) åbnes op for at samtaletyperne id 7 og 19 samtaletype 19 og 20 for a-kasser .

Jobcentret får WSRM på alle bookinger for egne borgere, og er således orienterede om bookingen.

¤UNDER AFKLARING: Det forventes at man ved fælles jobsamtaler registrerer deltagelse ved at opdatere BookingParticipantCollection, der laves en ny metode, UpdateBookingParticipantCollection til dette. Registreringer af fravalg af deltagelse i fællesmøder udgår, og de tilhørende valideringer ligeså.

¤Afklaring: På indkaldelse kan man under BookingParticipant.ContactDetails registrere det hvis deltagere ikke deltager fysisk ( eller BookingParticipant kan udvides med en InterviewContactType så man kan sætte deltagelsestype til Personlig kontakt/Telefon/.../Videokonference).

Samtaleafholdelse registreres med PersonRegistrationService hvor den nuværende mulighed for at registrere CV- og rådighedssamtaler under forudsætning af at borger har været dagpengemodtager på samtaleafholdelsesdatoen, udvides med jobsamtaler og fælles jobsamtaler.

Når samtaleafholdelse registreres anvendes InterviewParticipant.InterviewParticipantContactType til at indikere om man har deltaget fysisk (id 1 - Personlig kontakt), pr video (id 8) eller lignende. De nærmere detaljer om indkaldelse m.m. på Fællessamtale med dagpengemodtager vil blive behandlede i epic 935.2 i 2019-3 

¤¤¤

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

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.