Formål med service

Service benyttes til at oprette og vedligeholde data efter integrationslov for borger der er omfattet af integrationsloven. 

Denne service er forbeholdt Jobcenter, Anden Aktør og STAR. Servicen kan ikke anvendes af andre serviceaftagere, da det kun er de nævnte, der benytter disse data efter integrationslov når borger er omfattet af integrationsloven.

Forretningsbeskrivelse

Oprette og opdatere af data efter integrationslov

Data efter integrationslov oprettes og opdateres ved IntegrationslovService. Læsning med GetIntegrationslovsdata (GET /v1/Integrationslovsdata/{IntegrationslovdataIdentifier}). Hver gang metoden anvendes, laves en ny instans af data med egen GUID. 

• For asylansøgerer, der har fået tildelt asyl, skal der oprettes en fremtidig Overgivelsesdato m.v., inden data efter integrationslov oprettes, således bliver det også muligt at hente data efter integrationslov fra asyloperatøren (LetAsyl).
• For borgere, der familiesammenført, kan der oprettes en fremtidig eller historisk Overgivelsesdato m.v. inden data efter integrationslov oprette. På en familiesammenført er det dog ikke muligt at hente data efter integrationslov fra asyloperatøren (LetAsyl).
• For borgere, der har en eksisterende data efter integrationslov, skal der oprettes en historisk Overgivelsesdato. Herefter kan data efter integrationslov oprettes. 

Se Borgerindsats.AsylovergivelseService og metoden CreateAsylOvergivelse (POST /v1/Asylovergivelse) for nærmere beskrivelse.

Skiftespor (hentning af integrationskontrakdata i DFDG eller Letasyl)

Da data efter integrationslov, jf. flow fødes hos asyloperatøren (i systemet LetAsyl) og skal kunne hentes af jobcentret i perioden til jobcenteret selv tager / får ansvaret for borgeren, har DFDG en særlig metode til at hente fra Letasyl GetLetAsylIntegrationlov (GET /v1/LetAsylIntegrationlov) samt en metode til at overføre data efter integrationslov OverfoerLetAsylIntegrationlov (POST /v1/LetAsylIntegrationlov/action/transfer) se Borgerindsats.LetasylIntegrationslovService. 

Når jobcentret har overtaget ansvaret og gemt data første gang i DFDG vil integrationskontraktdata derefter hentes i DFDG. Se også 2024 (Nytænkning) - Integrationskontrakt og tidlig informationsudveksling fra asylcenter til kommune - inkl. CV oplysninger

Bemærk: Skiftespor har samme grundlogik både for CV og data efter integrationslov.

Sikkerhed i LetAsyl 

Jobcenteret kan kun få lov til at hente data fra asyloperatøren (LetAsyl):

1. Hvis borgerens jobcentertilknytning er hos det kaldende jobcenter, som helt på normal vis mod DFDG 
2. Den rigtige kommune er angivet.
   Da LetAsyl anvender kommunekode i deres sikkerhedsmodel og jobcenteret til DFDG kalder ind med jobcenter kode, skal DFDG udlede den korrekte kommunekode, der anvendes mod LetAsyl også for jobcentre, der har forpligtende samarbejder, Dette gøre DFDG ud fra den kommunekode, der er angivet i overgivelseskommunekode se Borgerindsats.AsylovergivelseService   
3. Hvis cpr.nr, der kaldes med ikke findes i LetAsyl kastes fejlkode 9289 - Invalid URL or unknown person civil registration identifier submitted to the asylum operator.
4. Hvis cpr.nr. findes i LetAsyl, men ikke findes i Udlændingeministeriets system IBS, kastes fejlkode 9289 også, da det er en del af UIM's webservicens sikkerhedsmodel, at borgerens CPR-nummer skal fremgå ved opslag i IBS matchende asylansøgerens person-ID. I sådanne situationer kan kommunen kontakte UIM/US for nærmere afklaring af årsagen hertil.

Min plan og kontraktdata efter integrationsloven

Kontraktdata efter integrationslov er en del af Min plan. Oprettelse/opdateringer til data efter integrationslov herunder ændringer til danskmål og vejleding ifm. manglende dansktilegenelse samt lukning i forbindelse med borger ikke længere omfattet af integrationslov udløser en ny version af Min plan og tilhørende events i forhold til Min plan.

Et nyt sæt af data efter integrationsloven vil resultere i en ny version af min plan. 

Hvis borger ikke længere er omfattet af integrationsloven, vil data blive fjernet fra Min Plan således, at der ikke længere eksisterer en reference dertil. Der dannes dermed en ny version af Min Plan, hvor data efter integrationslov er fjernet, men eventlisten på Min Plan vil indeholde eventet "Kontrakt efter integrationsloven er afsluttet" (id. 67). Ydermere vil eventlisten på Min Plan i denne situation også indeholde eventet "Kontrakt efter integrationsloven er opdateret" (id. 66), idet der er lavet en ny udgave af data efter integrationslov, som får tildelt en guid og bliver opdateret med slutdatoen.

OBS: Data efter integrationslov og invalid Min Plan. I modsætning til de øvrige elementer på Min Plan, vil integrationskontrakten forblive en del af Min Plan, i de tilfælde hvor den eksisterende Min Plan version er invalid på det tidspunkt en ny version af Min Plan dannes. 

Se også Borgerindsats.MinPlanService

WSRM beskeder / Webservicebesked

I forbindelse med data efter integrationslov er der en række events Borgerindsats.PlanVersionHaendelsesTypeCodeList, når en sådan event udløses, vil der på linie med andre Min plan events blive sendt en Min plan WSB og WSRM

WSRM

For WSRM se WsrmMessageService GetMyPlanVersionNotificationEventVersionX). 

WSB

For WSB se Borgerindsats.WSB.MinPlan.WSB (2024-2)

Eksisterende data efter integrationslov

Eksisterende data efter integrationsloven kan lægges ind vha. OverfoerLetAsylIntegrationlov (POST /v1/LetAsylIntegrationlov/action/transfer) metode. Det er Jobcentret selv, der tager stilling til, hvornår oprettelsen sker, men forretningsmæssigt skal det minimum ske første gang, der er ændringer til integrationskontraktdata eller ved i forbindelse med den førstkommende integrationssamtale. Det er Jobcentret (KSS), der selv mapper over til den nye struktur for integrationskontraktdata. 

Se valideringsregler mht. Overgivelsesdato i Borgerindsats.AsylovergivelseService.

Kontrakt efter INL for familiesammenført m.v., jf. § 2, stk. 3

For borgere, der er familiesammenført m.v., er det muligt at oprette data efter integrationslovdirekte på OverfoerLetAsylIntegrationlov (POST /v1/LetAsylIntegrationlov/action/transfer). 

Borger er ikke længere omfattet af integrationsloven

Er en borger er ikke længere omfattet af integrationsloven fjernes dette ved at kalde metoden AfslutKontrakt og sætte en slutdato. Når en borger er ikke længere omfattet af integrationsloven lukkes, foregår det ved, at der laves en kopi af de eksisterende data. Denne kopi bliver gemt, som den seneste udgave af borgerens integrationslovdata, der tilhører borgeren, med den angivne slutdato (KontraktSlutdato). Det er derfor også muligt at angive et id, hvis det ønskes at de nyoprettede data skal have et (hvis et id ikke angives i kaldet, tildeler DFDG et guid til det lukkede sæt af integrationslovsdata). Det vil sige at den "integrationslovsdataIdentifier" som kan angives i kaldet ikke må være den samme som guid'en for den integrationskontrakt, der lukkes, da der i så fald vil eksistere to kontrakter efter INL med samme id og dette er ikke tilladt.

Når en en borger er ikke længere omfattet af integrationsloven og data lukkes, berører metoden kun data der direkte er knyttet til datasættet. Eventuelle fravær, aktiviteter, registreringer i forhold til plan m.v. berøres ikke. De skal håndteres separat i de relevante services af en sagsbehandler.

Håndtering af fejloprettede data

Der er ikke eksplicit understøttelse for at markere data som værende fejloprettet. 

Aktiv data efter integrationslov for en borger

Så længe der er data efter integrationsloven på en borger er den aktiv i forhold til Jobnet. Det er først når en sagsbehandler registrerer, at en borger er ikke længere omfattet af integrationsloven, den forsvinder i forhold til borger på Jobnet. Se afsnit Borger er ikke længere omfattet af integrationsloven.

Metoder

CreateIntegrationslov (POST /v1/Integrationslov)

Metoden oprettet data efter integrationsloven for en borger i DFDG.

Forretningsregler

• Integrationskontraktdata kan først gemmes på eller efter den tidlige overtagelsesdato for integrationskontrakt (EarlyIntegrationContractTransitionDate), hvis denne er angivet (se AsylumService for regler for hvornår der må oprettes en tidlige overtagelsesdato m.v.).
• Hvis der er angivet en overgivelsesdato (AsylumTransitionDate) men ingen tidlig overtagelsesdato (EarlyIntegrationContractTransitionDate), kan integrationskontraktdata først gemmes på eller efter overgivelsesdato.
• Hvis hverken overgivelsesdato (AsylumTransitionDate) eller den tidlige overtagelsesdato (EarlyIntegrationContractTransitionDate) er angivet, kan integrationskontraktdata gemmes. 
• Der laves et ny kopi (selvstændig GUID), hver gang der oprettes en ny ”udgave” af integrationskontrakten i DFDG, hvilket sikrer, at der laves fuld tilgængelig historik fra MinPlan og GetIntegrationslovsdata (GET /v1/Integrationslovsdata/{IntegrationslovdataIdentifier})
• Ved angivelse af datoen for underskrift af første kontrakt (IntegrationContractFirstSigningDate), skal denne ligge tilbage i tiden eller være lig med dags dato.
• Ved angivelse af slutdato for integrationsprogrammet (IntegrationProgramEndDate) og der på integrationskontrakten er angivet en startdato for integrationsprogrammet (IntegrationProgramStartDate), så kan angivne slutdato for integrationsprogrammet (IntegrationProgramEndDate) ikke ligge længere tilbage end startdatoen for integrationsprogrammet (IntegrationProgramStartDate).
• Ved angivelse af sprog i kollektionen hertil, skal hvert enkelt sprog identificeres med enten en kode for sproget (sprogkode) eller det danske navn for sproget (sprognavn). Det er således ikke muligt at udelade begge værdier hertil, ligesom det ikke er muligt at angive begge værdier.
• Ved angivelse af sprog i kollektionen hertil, skal de sprog, som er identificeret med en kode for sproget (sprogkode), være kendt i DFDG’s kodeliste over sprog (LanguagesTypeIdentifier).
• Ved angivelse af sprog i kollektionen hertil, skal hvert enkelt sprog være unikt. Det er således ikke muligt at angive:
  • To eller flere sprog i kollektionen med den samme kode for sproget (LanguageCodeTypeIdentifier).
  • To eller flere sprog i kollektionen med det samme danske navn for sproget (sprognavn).
  • Et sprog i kollektionen, hvor koden for sproget (eksempelvis 10) matcher et andet sprog i kollektionen, hvor det danske navn for sproget er angivet (eksempelvis Dansk).
• Ved angivelse af datoen for, hvornår der sidst er givet meddelelse til udlændingen om konsekvenserne om manglende dansktilegnelse, jf. bek. § 15, stk. 9 og 11 (senesteMeddelesesDato), skal denne ligge tilbage i tiden eller være lig med dags dato.
• Ved angivelse af datoen for, hvornår der sidst er vejledt vedr. konsekvenserne vedr. manglende dansktilegnelse, ifht I-ydelsen, familiesammenføring, tub (senestVejledtOmKonsekvensDato), skal denne ligge tilbage i tiden eller være lig med dags dato.
• Ved angivelse af datoen for, hvornår der sidst er vejledt om, at medbragt formel uddannelse kan vurderes af Styrelsen for Videregående Uddannelser (senestVejledtDato), skal denne ligge tilbage i tiden eller være lig med dags dato.

GetIntegrationslov (GET /v1/Aktivitet/{IntegrationslovIdentifier}) - GetIntegrationslovsdata, GetSenesteIntegrationslovsdata

Metoderne GetIntegrationslovsdata og GetSenesteIntegrationslovsdata henter integrationskontraktdata fra LetAsyl / DFDG. Førstnævnte metode kalde med id. Sidstnævnte kaldes uden id.

Forretningsregler

• Integrationslovsdata kan ikke hentes i LetAsyl, med mindre der er oprettet Overgivelsesdato (AsylumTransitionDate) og en modtagende kommune (TransitionAythority).
• Kun den kommune, der modtager flygtningen (TransitionMunicipality) og som vil være angivet i CVService.CreateAsylumTransition/UpdateAsylumTransition, kan hente data i LetAsyl.
• Det er den seneste udgave af borgerens integrationslovsdata, der hentes, hvis der ikke er angivet en specifik integrationslovsdataIdentifier (guid). Har borgeren ikke integrationslovsdata returneres et tomt response.
• Det er den specifikke udgave af borgerens integrationslovsdata, der hentes, hvis der angives en specifik integrationslovsdataIdentifier (guid). Har borgeren ikke en udgave af integrationslovsdata med denne specifikke integrationslovsdataIdentifier fejler metoden.

Mapning af data fra LetAsyl 

Når der integrationskontraktdata hentes data fra LetAsyl sker der en mapning fra LetAsyl struktur til den struktuer der udstilles i GetIntegrationContract. for mapningsregler se 752.4 Bilag 1 Letasyl-DFDG mapning af snitflader. 

Tekstformatering / HTML

Når der hentes data fra LetAsyl vil DFDG fjerner de html tags fra tekstfelterne, som beskrevet i afsnittet "Tekstformatering / HTML" under 2024 (Nytænkning) - Integrationskontrakt og tidlig informationsudveksling fra asylcenter til kommune - inkl. CV oplysninger.

AfslutKontrakt (PUT /v1/AfslutKontrakt)  - AfslutKontrakt og AfslutSenesteKontrakt

Metoderne AfslutKontrakt og AfslutSenesteKontrakt lukker en integrationskontrakt. Førstnævnte metode kalde med id. Sidstnævnte kaldes uden id.

Forretningsregler:

• Slutdato for kontrakten (kontraktSlutdato) skal ligge tilbage i tiden eller være lig med dags dato.
• Slutdato ikke kan ligge længere tilbage end datoen for underskrift af første kontrakt (foersteUnderskriftsdato), hvis denne dato er angivet for kontrakten.