Hovedoplysning
778 CV for flygtninge og familiesammenførte
IT-slutproduktbeskrivelse af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning Se følgende vejledninger:
Projektets dokumenter til beskrivelse af IT
Releaseprocessen og epic versioner
- Indhold
2. Ændringslog
3. Målgruppe for dokumentet
4. Baggrund
5. Forretningsmål
6. Løsningens grænseflader
Overordnet flow
Detaljeret løsningsmodel for LetAsyl, DFDG og Jobcenter (KSS)
Asyldata hentes første gang
Opdatering af CV
Opdatering af integrationskontrakt og øvrige asyldata
Generelle regler for opdatering af asyl data
7. Løsningens omfang
8. Oversigt over epics
Ændringslog
Dato | Version | Forfatter | Berørte afsnit |
08-09-2016 | 0.1 | LNV | Oprettelse |
22-09-2016 | 0.2 | LNV | Afsnit 4 og 6 |
20-12-2016 | CO | Afsnit 6 med løsningsmodeller er flyttet fra 778.1 Modeller dækker både CV, integrationskontrakt og øvrige asyldata og der nu et tvillingprojekt mellem CV og integrationskontrakten | |
04-01-2017 | CO | Opdateret efter møde med KL, Kombit, UIM og STAR, med valg overordnet løsning |
Målgruppe for dokumentet
Navn på interessent omfattet af ændringen |
DFDG |
Jobnet |
KSS |
Baggrund
Når asylansøgere kommer til Danmark bliver de modtaget af en asyloperatør, fx Røde Kors. I perioden, hvor asylansøgerens ansøgning om ophold i Danmark behandles, foretager asyloperatørerne en tidlig kompetenceafdækning af asylansøgerne. Hvis en asylansøger tildeles asyl overføres de til den kommune, de skal flytte til.
Kompetenceafdækningen foretaget af asyloperatøren har ikke tidligere været garanteret at lande i modtager kommunen. Det har ført til dobbeltarbejde, da kommunen således er startet forfra med afklaring af asylanternes kompetencer.
Det er besluttet, at kompetenceafdækningen skal ensrettes og digitaliseres, så informationer automatisk tilgår modtagerkommunen, så de ikke går tabt.
Asyloperatørerne indtaster kompetenceafklaringen i systemet Let Asyl, der skal være ensrettet med CV på Jobnet.
Forretningsmål
- At kommunen modtager de relevante informationer, som asyloperatøren har afdækket
- At DFDG/Jobnet får relevante CV data til brug for asylantens færden i Jobnet regi
Løsningens grænseflader
Overordnet flowMå kun vedligeholdes på WS-wiki
Det overordnede flow dækker håndtering at alle asyldata og er derfor fælles for de to projekter for henholdsvis CV og integrationskontrakt data (samt øvrige asyl data). Dokumentet 778 - Data - tidlig informations overgivelse og integrationskontrakt til Min plan - analyse gennemgår alle data, der skal udveksles. NB: der er tale om et levende arbejdsdokument.
Flowet vedrørende flygtning er opdelt i fire delflows:
- Oprettelse og vedligeholdelse af asyldata
- Asyloperatørenes opdatering af asyldata i LetAsyl
- Visitering i Udlændingestyrelsen
- Advisering af den kommunale integrationsforvaltning
I dette delflow er det asyloperatøren (LetAsyl) der vedligeholder asyldata
Dette delflow beskrives ikke i detaljer i dette dokument.
- Initiering af borgers sag i Jobcenter og løbende afhentning af asyldata fra asyloperatører (LetAsyl) I dette delflow er det stadig asyloperatøren (LetAsyl) der vedligeholder asyldata frem til kommunen overtager ansvaret. Dette sker senest når overgivelsesdatoen nås.
- Opdatering af CV data på eller efter evt. tidlig overtagelsesdato eller overgivelsesdatoHer er det Jobcentret der har ansvaret for opdatering af CV og der hentes som udgangspunkt ikke længere asyl data fra asyloperatøren (LetAsyl), dog med den undtagelse at der hentes indtil data fra Letasyl indtil CV date er gemt i DFDG
- Opdatering af Integrationskontraktdata på eller efter evt. tidlig overtagelsesdato eller efter overgivelsesdatoHer er det Jobcentret der har ansvaret for opdatering af integrationskontrakten og der hentes som udgangspunkt ikke længere asyldata fra asyloperatøren (LetAsyl), dog med den undtagelse at der hentes indtil data fra Letasyl indtil CV date er gemt i DFDG
Bemærk at de øvrige asyldata alene gøres tilgængelig for jobcentret i en periode, Jobcentret skal ikke opdaterer i disse data.
Detaljeret løsningsmodel for LetAsyl, DFDG og Jobcenter (KSS)
Gennem afklaringen har der være en række forskellige modeller i spil. Disse omfatter bl.a. om det var KSS eller DFDG der skulle integrerer mod LetAsyl/serviceplatform og hvorvidt Kombit's Serviceplatform skulle være en del af arkitekturerne mod LetAsyl. Disse modeller ikke yderlige beskrevet her, heller ikke de beslutninger der har ledt frem til nedenstående model. For yderlig beskrivelse af disse modeller henvises bl.a. til tidligere versioner af epic og ISB for 778.
Fordel og ulemper ved den valgte model: er et alternativt til model a og er under vurdering og den har følgende fordel og ulemperSe også ALL ark.
- Fordel for borger gennem en bedre brugeroplevelse på Jobnet
- Ulempe for DFDG de skal lave snitflade til LetAsyl der er en ny interessent for DFDG og fortage mapning af asyl CV data til DFDG's servicesnitflade samt gemme integrationskontakt data og øvrige asyl data
- Fordel for KSS, er at ikke skal gemme asyl data lokalt og kan hente asyl CV, integrationskontakt data og øvrige asyl data via en for dem kendt snitflade i DFDG
- Ulempe DFDG kan ikke vide hvornår der skal hentes nye asyl data fra Let Asyl inden overgivelsesdatoen, Denne model forudsætter derfor en af følgende løsninger:
- Der en knap i KSS systemet der giver DFDG besked om at hente igen(Dette kræver 24/7 oppetid og gode svartider fra LetAsyl)
- DFDG spørger LetAsyl hver gang KSS kalde GetCV eller en af de andre metoder med asyl på serviceplatform når overgivelsesdatoen (+ x dage) ikke er overskredet
- Skiftespor der skifter mellem at proxy til LetAsyl inden overgivelsesdato og til DFDG efter overgivelsesdato, DFDG vil henter data i LetAsyl på overgivelsesdatoen (via batchjob) og gemme disse i DFDG (Dette kræver 24/7 oppetid og gode svartider fra LetAsyl)
- DFDG får en notifikation fra LetAsyl til KSS og DFDG v ved nye oplysninger.(Det kræver LetAsyl laver en lille dims der kalder DFDG ved nye data på en person, derefter hente DFDG)
- Der er et batchjob der henter hver nat (løse ikke hvis der er opdateringer sammen dag)Denne ulempe kan muligvis elimineres når den endelige snitfladen mellem DFDG og LetAsyl aftales(Det kræver at JC kan leve data er op til 1 dag gamle)
- Der er et batchjob der f.eks. hver 15 min spørger LetAsyl om hvilke borger der er ændret og derefter henter data for disse borger
- DFDG udstiller en service som LetAsyl kalder hver gang en relevant borger får opdateret sine asyl data i LetAsyl(Dette kræver at DFDG udstiller service til LetAsyl) Ved dette er en anden model end da serviceplatformen var med men det er de jo ikke mere så vi bør nok genbesøge denne model. Fordelen her er at der kan komme andre asylsystemer end LetAsyl og vi er ikke direkte afhængin af oppetid/servicevinduer m.v. i LetAsyl
- Ulempe: Alle de nævnte løsninger i forrige dot, gør løsningen mere kompliceret for DFDG
- Fordel for KSS og DFDG at der kun er en part der skal integrere til LetAsylserviceplatformen
- Fordel for KSS de vil få mappet integrationskontakt data og skal ikke selv gøre dette
- Fordel for KSS og DFDG, alle data om borger er i DFDG ved flytning
Bemærk vælges model b skal der laves en epic i 17-3 der udvides med nyt acceptkriterier (udvidelse til 778.1.1)!
*I de følgende diagrammer er flow delt i tre selvstændige diagrammer for overblikket skyld.*Disse bør slettes her, da de findes og skal vedligeholdes på WS-wiki
- Asyldata hentes første gangInitiering af borgers sag i Jobcenter og løbende overførsel af asyl data fra Asyloperatører/LetAsyl
- Opdatering af CV
- Opdatering af integrationskontrakt og øvrige asyldata
Asyldata hentes første gang
Kort beskrivelse af flow omkring asyl CV og integrationskontrakt mellem de forskellige interessenter
Flow asyl data hentes af DFDG første gang (Bemærk Trin 1, 2, 4 og efter 11 beskrives ikke her) |
|
Jobcenter (KSS) håndteringe af asyl data |
|
Flow for CV og Integrationskontrakt samt øvrige asyl data beskrives separat |
Opdatering af CV
Flow CV data opdateres i DFDG (Bemærk Trin 1, 2, 3a, 3b, 4, 5, 6, 7 og efter 11 beskrives ikke her) |
|
- Opdatering af integrationskontrakt og øvrige asyldata
Flow Integrationskontrakt data opdateres i DFDG (Bemærk Trin 1, 2, 3a, 3b, 4, 5, 6, 7 og efter 11 beskrives ikke her) |
|
Generelle regler for opdatering af asyl data
Figuren viser en oversigt over hvem der må opdaterer i asyl data alt efter hvor i forløbet det er.
Bemærk af nedenstående gælder både model a, b og d dog skal der ske udvidelser hvis model b eller d vælges
Løsningens omfang
Oversigt over epics
ID | Titel | Del af MVS MVS: Minimum Viable Solution |
778.1 | X 17-1 | |