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

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

https://starwiki.atlassian.net/browse/JOB-7766

https://starwiki.atlassian.net/browse/DS-10088

Indholdsfortegnelse

Afgrænsning af epic

Pakke MINPLAN-1 i DFDG moderniseringsroadmap Version 0.6 - KUN INTERN

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

Automatisk oversigt

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

Omlægningen indgår i omlægning af Min plan komplekset

Omlægningen indgår i omlægning af Min plan komplekset:

Beskrivelse af epic

Baggrund

Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til Min plan og aktiviteter følgende:

• I DFDG et skift til REST snitflade - og i denne epic med mindre forretningsmæssige ændringer

• I Jobnet en overgang til ny REST snitflade samt ny frontend arkitektur (denne opgave er ikke en del af denne epic, men vil blive specificeret i en efterfølgende epic)  

Regler

Der er ikke større ændringer til den overordnede forretning, kun mindre justeringer i felter, forekomst (occurrence) og valideringsregler.

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Omlægning til REST service inklusiv mindre forretningsændringer på udvalgt felter og valideringsregler. Bemærk, der etableres ikke SOAP-REST converter på Aktivitetsservice (pga. breaking-change ift. valideringer med afledte konsekvenser ift. om felter skal være udfyldt).

1005.17.45.1 ActivityService omlægning til REST som en del af samlet Min plan modernisering

Løsningmodel

Som en del af DFDG’s modernisering samt Nytænkning af beskæftigelsesindsatsen bliver Min plan komplekset (Min plan, Plan, uddannelsesplan, aktiviteter, samtaler, krav til jobsøgning og integrationskontrakt) flyttet til forretningsdomæner Borgerindsats. I denne epic vil der ske følgende:

• Etablering af database i Borgerindsats

• Løft eksisterende ActivityService ind i forretningsdomæne Borgerindsats som REST snitflade

  • Der etableres ikke SOAP - REST converter på aktivitetsservice, da der er snitflade ændringer

• Fejlkoder bevares

• Der ændres ikke i adgangsforhold til service/metoder 

• WSRM / webservicebesked afsendes til jobcentre og a-kasse efter eksisterende regler

• Der etableres moderne webhooks besked (WSB) parallelt med WSRM.

Borgerindsats.AktivitetService -

Ny service erstatter, der erstatter .

Bemærk der er ikke SOAP-REST converter pga. snitfladeændringer i forekomst.

Bemærk: Borgerindsats.JobtilbudTypeCodeList og Borgerindsats.MyndighedsomraadeTypeCodeListse er nu to kodelister der erstatter . Se mapning i

CreateAktivitet (POST /v1/Aktivitet)

Ny metode, der erstatter CreateActivity

Updateaktivitet (PUT /v1/Aktivitet/{AktivitetIdentifier})

Ny metode, der erstatter UpdateActivity

GetAktivitet (GET /v1/Aktivitet/{AktivitetIdentifier})

Ny metode, der erstatter GetActivity

GetAktiviteter (GET /v1/Aktiviteter)

Ny metode, der erstatter GetActivities

Getaktiviteter (GET /v1/Aktiviteter?Tilskundsansaettelser)

Ny metode, der erstatter GetSubsidyJob

Getvirksomhedsaktiviteter (GET /v1/Virksomhedsaktiviteter/?CVR={cvrEnhedsid}&Pnr={pNummer}&startdato={startdato}&slutdato={slutdato})

Ny metode, der erstatter GetCompanyActivitySummaries

Getaktiviteter (GET /v1/Jobcenter/{Jobcenterkode}/Aktiviteter?fradato={fradato}&tildato={tildato}&aktivitetsType={aktivitetsType&}aendretIPerioden={aendretIPerioden}&sidenummer={sidenummer}&sidestoerrelsen={sidestoerrelsen})

Ny metode, der erstatter GetActivitiesByJobCenter

ActivityService -

Udgår i 2024-2. Bemærk der er ikke SOAP-REST konverter

1005.17.45.2 DFDGs aktivitetsregistreringsservice skal kunne modtage oplysninger om mentor (eksisterende aktivitetstype) af typen "personlig jobformidler" uden time- eller minuttal for aktivitetens omfang - og for visse aktivitetstyper skal slutdato, CVR-nr m.v. ikke længere udfyldes

Baggrund

For mentor (eksisterende aktivitetstype) af typen "personlig jobformidler" er der i lov- og bkg. regler ikke bestemmelser om, at der skal fastsættes time- eller minuttal for aktivitetens omfang. Derfor udgår det tekniske krav om obligatorisk registrering herom i snitfalden.

For visse social- og sundhedsaktiviteter bevilges / registreres disse i deres fagsystemer på det sociale og sundhedsmæssige område uden oplysninger om slutdato (ofte bevilges “indtil videre”) og ofte uden oplysninger om udbyder.

For at undgå registrering af forkerte / misvisende / fiktive oplysninger af hensyn til DFDG snitfladevalidering udgår det tekniske krav om obligatorisk registrering derfor i snitfladen. Dette også af hensyn til GDPR-reglerne - bl.a. databeskyttelsesforordningens artikel 5, stk. 1, litra d, hvorefter personoplysninger skal være korrekte og om nødvendigt ajourførte; der skal tages ethvert rimeligt skridt for at sikre, at personoplysninger, der er urigtige i forhold til de formål, hvortil de behandles, straks slettes eller berigtiges.

Løsningmodel

• I Ny REST udgave af service indføres nedestående forretningsændringer

Ændringer til krav om angivelse af visse oplysninger

Fra obligatorisk til valgfri udfyldelse/angivelse af visse oplysninger

I  kommende rest-versioner af 

• tidligere ActivityService (version 6)

• tidligere MyPlanService (version 6)

• JobnetMyPlanService (version 6) (Udgår)

  foretages ændringer i snitflade (og nødvendige konsekvensændringer database?) sådan, at Forekomst ændres fra "1" til "0-1" for 

• elementerne timerPrUge (tidligere HoursPerWeek), minutterPrUge (tidligere MinutesPerWeek) og slutdato (tidligere EndDate) i aktivitetsstamdata (tidligere ActivityCoreItem)

• i elementet aktivitetsudbyder (tidligere ActivityProvider) i aktivitetsstamdata (tidligere ActivityCoreItem)

  • cvrEnhedsid (tidligere CVRNumberIdentifier)

  • pNummer (Tidligere ProductionUnitIdentifier)

Men ændringen kombineres med samtidig indførelse af forretningsmæssige valideringer for de aktivitetstyper, hvor oplysningerne skal være angivet:

Samtidig indførelse af forretningsmæssige valideringer

Der indføres samtidig forretningsmæssig validering for, at 

• timerPrUge (tidligere HoursPerWeek) eller minutterPrUge (tidligere MinutesPerWeek)

• cvrEnhedsid (tidligere CVRNumberIdentifier)

• pNummer (Tidligere ProductionUnitIdentifier)

• slutdato (tidligere EndDate)

er udfyldt for aktiviteter af typerne:

• virksomhedsrettetAktivitet (tidligere CompanyActivity)

• kursusaktivitet (tidligere CourseActivity)

• personligAssistance (tidligere PersonalAssistanceActivity)

• mentor (tidligere MentorActivity) fsva mentorType (id 1-5)

Og dermed ikke for 

• Hjaelpemiddel (tidligere HelpingDeviceActivity

• sundhedsindsats (tidligere HealthActivity)

• socialindsats (tidligere SocialActivity)

• mentor (tidligere MentorActivity) fsva mentorType (id 6)

Oversigt over ændringer

Udvikingsversion af Aktivitetsservice

Borgerindsats.AktivitetsService - teknisk underside med snitfladebeskrivelse

Udviklingsversion af kodelister

Se relevante undersider til Borgerindsats.CodeLists 

1005.17.45.3 Som STAR vil jeg have dataleverancer i forhold til DOA tilpasset til det nye forretningsdomæne (silo) inkl. kontaktperson i DOA

Intern STAR acceptkriterier

Løsningsmodel

• Initial load af data / konvertering fra DFDG (Classic) til Borgerindsats

• Tilpasning af dataleverance fra DFDG/BK til DOA via BI

1005.17.45.4 Kodelister i forbindelse med DFDG omlægger ActivityService

Løsningsmodel

• Borgerindsats udstiller kodelister for aktiviteter

Se for indhold.

Borgerindsats.JobtilbudTypeCodeList og Borgerindsats.MyndighedsomraadeTypeCodeListse er nu to kodelister der erstatter . Se mapning i

Øvriger kodelister er indholdsmæssigt uændret

1005.17.45.5 Som STAR vil jeg have at dokumentation for såvel servicelag og frontend lever op til STAR's principper på releasetidspunktet

Intern STAR acceptkriterier

Løsningsmodel

• QA af regler fra kode mod dokumenteret regler og fejlkode

• Ajourfører dokumentation

Sider der skal rettes og QA er (liste er ikke udtømmende)

• Servicesnitflade 

1005.17.45.6 Som STAR vil jeg have, at data er omfattet af dataløft og pseudonymisering mod testmiljøer

Intern STAR acceptkriterier

Løsningsmodel

• Tilpasning af regler af for pseudonymisering og aftale hvornår data skal med i dataløft

• Systemforvalter til retter pseudonymiseringsflow 

1005.17.45.7 DFDG konverterer oplysninger fra ActivityService (DFDG classic) til AktivitetsService i Borger indsats domænet.

Intern STAR acceptkriterier

Løsningsmodel

• Konvertering af eksisterende aktivitetsdata ind i ny datamodel i BorgerIndsats.

Acc. kr. 1005.17.45.8 DFDG etablerer nødvendig domæne arkitektur elementer f.eks. Eventreceivere

Intern STAR acceptkriterier

Løsningsmodel

• Eventreceivere for CPR Stamdata, jobcentretilknytning, a-kasse tilknytning

1005.17.45.9 Landssupport/LSS og Datakanon er skiftet over til at brug den nye REST-servicen i borgerindsats.aktivitetsservice, i stedt for ActivityService fra DFDG classic

Intern STAR acceptkriterier

Løsningsmodel (internt STAR acc.kr.)

• Landssupport/LSS er skiftet til at brug borgerindsats.aktivitetsservice ved brug af nyt ClientApi fra Borgerindsats.

• Kode brugt i forbindelse med ActivityService er fjernet fra LSS

1005.17.45.10 - Død kode i DFDG, i forbindelse med stamdata om (sub)jobcentre, fjernes

Intern STAR acceptkriterier

Løsningsmodel (internt STAR acc.kr.)

• Fjernelse af gammel og død kode i DFDG classic. Dette samles i en US på tværs af hele Min plan se epic

1005.17.45.11 Udsendelse af webservicebeskeder og udfasning af WSRM (se epic 1005.17.48)

For afsendelse at WSB (og WSRM) se forretningsdokumentation

• WSRM (Bemærk at WSRM og denne udsendelses logik udfases, men bevares i en overgangsperiode)

• WSB

Ny webservicebeskeder er beskrevet og vil blive implementeret i regi af epic

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.

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin