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

DS-290 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

¤?? Afholdte møder som er selvbookede indberettes ligeledes som selvbookede (kan/gør vi allerede dette?)

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

Indtil LAB har det i lovgrundlaget for borgers selvbook af samtaler til afholdelse i Jobcenterregi været defineret at det skulle foregå på Jobnet.

Det bliver der lavet om på med LAB, så det bliver muligt at indberette borgers selvbookede aftaler som selvbookede i eksempelvis lokale plannersystemer eller apps.

I vid udstrækning løses dette ved at DFDG modtager aftaler (bookings) i BookingService hvor feltet SelfBooked indikerer at aftalen er selvbooket af borger.

Aftaler med denne påtegning vil som alle andre blive udstillet til borger på Jobnet. De forventes at have BookingAccepted = TRUE (borger har accepteret bookingen) og BookingAcceptedTime sat. I modsat fald vil man få fejl: ¤fejl afklares.

Ansvar for udstiller af brugergrænsesnitflade ift. overholdelse af frist til selvbook med henblik på samtaleforløbets kadence af samtaler

I de tilfælde hvor borger har en frist til selvbooking vil det i et vist omfang påhvile det system som stiller brugersnitflade til rådighed for borgeren at sikre at borger ikke får mulighed for at booke til afholdelse jf. den udstedte frist

¤¤¤

Gennemgang af ønsket funktionalitet

Huskeservicebeskeder sendes med udgangspunkt i at det er borger selv der har booket.

Afklaringer

Er der behov for øget udstilling af hvilket system der har initieret en booking?

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.