Denne epic er en udvidelse af epic 903.5 og har således ophæng i LAB.
| Page Properties | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Indholdsfortegnelse
| Table of Contents | ||
|---|---|---|
|
Afgrænsning af epic
Afgrænsning | ||||||
|---|---|---|---|---|---|---|
Som en sagsbehandler vil jeg have forbedret statusfeltet (teknisk kaldt evaluering), så jeg kan lave flere statusser på borgeren udover aktiviteter (indsatser). | ||||||
Acceptkriterier | ||||||
Nr. | Beskrivelse | Relevant for | ||||
903.6.1 | Som sagsbehandler vil jeg kunne registrere status på nye prædefinerede elementer, i denne kontekst også borgerens jobmål | DFDG | ||||
903.6.2 | Som sagsbehandler vil jeg kunne registrere en progression i forbindelse med en status, så jeg kan få et overblik over udviklingen over tid. Denne progressionsmåling er intern for mig som sagsbehandler | DFDG | ||||
903.6.3 | Som sagsbehandler vil jeg kunne lave status på valgfrie forhold, hvor jeg som sagsbehandler selv kan definere de forhold jeg ønsker at følge op på | DFDG | 903.6.4 | Som 4 | Som tester vil jeg i LSS kunne registrere løbende og afsluttende statusser for at mit testarbejde bliver mere effektivt | DFDG |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||||
|---|---|---|---|---|---|---|---|
903.6.1 | 903.6.2 | 903.6.3 | 904.6.4 | ||||
Som Jobcenter sagsbehandler vil jeg nu kunne evaluere på de nye forud defineret elementer | X | X | Som Jobcenter sagsbehandler vil jeg nu kunne evaluere på de nye valgfrie elementer | X | |||
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)
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Beskrivelse af epic
Denne epic er en opsamling i forhold til LAB og anvendelse af evalueringer (løbende og afsluttende status) på aktiviteter.
Der gøres opmærksom på, at ordvalget "evaluering" anvendes til teknisk beskrivelse i snitfladen og i koden, men vil i brugergrænsefladen for borger på Jobnet blive kaldt for "status" (både til løbende og afsluttende status). Det samme gør sig gældende i lovgivningen.
Løsningsmodellen
Gøre metoder åben for at kunne lave status på andre foruddefinerede elementer i beskæftigelsesindsatsen ud over aktiviteter, her Jobmål. Kun status på aktivitet bliver synlig for borger på Jobnet.
Gøre metoder åben for at kunne lave en simpel progressionsregistrering, så sagsbehandler kan følge en udvikling (denne del vil ikke være tilgængelig for borger på Jobnet)
Give mulighed for at angive, at status ikke er relevant
Udvidelse på hent af status (evaluering) i GetMetode, bl.a. i forbindelse med flytning er der behov for at kunne se, hvilken myndighed og sagsbehandler, der har foretaget registrering af statussen (kun nye metoder)
Forbedre testprocessen ved at STAR-tester, kan anvende LSS
Bedre navngivning
Status uden foruddefinerede elementer
Ønsket om at gøre metoder åben for at kunne evaluere på valgfrie elementer, som ikke er foruddefinerede, er p.t udenfor scope, pga. tid i 2020-1 men den bør indgå som en del af en opfølgning, når vi har flere erfaringer.
Mapning og lovlige værdier mellem elementer og evalueringer
Id | EvaluationElementTypeIdentifier | Id | EvaluationTypeIdentifier |
|---|---|---|---|
1 | Aktivitetsevaluering | 1 | Afsluttende status evaluering |
2 | Løbende status evaluering | ||
3 | Ingen evaluering er relevant | ||
2 | Jobmålsevaluering | 4 | Jobmålsevaluering |
3 | Ingen evaluering er relevant |
903.6.1 Som sagsbehandler vil jeg kunne registrere status på nye prædefinerede elementer, i denne kontekst også på borgerens jobmål +
903.6.2 Som sagsbehandler vil jeg kunne registrere en progression i forbindelse med en status
EvaluationService (Version 1)
Ændres ikke
EvaluationService (Version 2, [UDV] 2020-1)
Følg link
GetCreateEvaluations
Udvides med de nye felter
CreateEvaluation
Forretningsregler (Grønt er nyt)
- STAR, borgers Jobcenter og a-kasse må oprette, opdatere og slette en status
- Der valideres på, at en eventuel medsendt ID ikke findes i forvejen
- Det valideres at elementet (aktiviteten eller jobmålet) findes og hører til samme borger.
- "Ingen evaluering er relevant" (Id 3) må anvendes på alle typer af evalueringer
"Ingen evaluering er relevant" (Id 3) kan kun sættes, hvis der ikke er andre aktive evalueringer
- Hvis "Ingen evaluering er relevant" (Id 3) er sat og er aktiv, må der ikke laves andre evalueringer på elementet
- Der må kun laves en afsluttende evaluering af en aktivitet ("Afsluttende status evaluering" (Id 1)), der kan laves flere løbende evalueringer "Løbende status evaluering" (Id 2)
- Der må laves flere "Jobmålsevaluering" på et jobmål fra Min plan
- Der kan kun laves "Jobmålsevaluering" på et jobmål der er angivet i Min plan, kun aktive jobmål kan evalueres (dette er pga. at mål stadig ligge på den snævre plan)
- Ved oprettelse af en evaluering af typen (EvaluationTypeIdentifier):
- "Afsluttende status evaluering" (Id 1) dannes en ny Min plan version og hændelsen "Ny evaluering på aktivitet" (Id 68) sættes.
- "Løbende status evaluering" (Id 2) dannes en ny Min plan version og hændelsen "Ny evaluering på aktivitet" (Id 71) sættes
- Andre evalueringer danne ikke en ny version af Min plan
- Hvis progrationsfelterne udfyldes er det serviceaftager der skal sikre at der er logisk sammenhæng på tværs af evalueringer af et element f.eks. at skalanes min og max værdier er sat ens.
UpdateEvaluation
Forretningsregler (Grønt er nyt)
- Kun STAR, borgers Jobcenter og a-kasse må oprette, opdatere og slette en evaluering
- Jobcenter og a-kasse skal dog kunne opdatere egne evalueringer (DFDG validerer ikke for dette)
- Der valideres for, om evalueringen hører til den medsendte borger
- Id skal findes ellers kastes en fejl.
- Der valideres ikke for status på aktiviteten eller start/slutdato.
- Der valideres ikke for, om jobmålet er på aktuel Min plan
- Ved opdatering af en evaluering af typen (EvaluationTypeIdentifier):
- "Afsluttende evaluering" (Id 1) dannes en ny Min plan version og hændelsen "Evaluering på aktivitet opdateret" (Id 69) sættes.
- "Løbende evaluering" (Id 2) dannes en ny Min plan version og hændelsen "Løbende evaluering på aktivitet opdateret" (Id 72) sættes
- Andre evalueringer danne ikke en ny version af Min plan
- Hvis progressionsfelterne opdateres, er det serviceaftager, der skal sikre, at der er logisk sammenhæng på tværs af evalueringer af et element f.eks. at skalaens min og max værdier er sat ens.
DeleteEvaluation
Forretningsregler (Grønt er nyt)
- Ved sletning af en evaluering af typen (EvaluationTypeIdentifier):
- "Afsluttende evaluering" (Id 1) dannes en ny Min plan version og hændelsen "Evaluering på aktivitet slettet" (Id 70) sættes.
- "Løbende evaluering" (Id 2) dannes en ny Min plan version og hændelsen "Løbende evaluering på aktivitet slettet" (Id 73) sættes
- Andre evalueringer danner ikke en ny version af Min plan
CodeListService (Version 5)/wiki/spaces/GI/pages/1403355165
EvaluationElementTypeIdentifier
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
|---|---|---|---|---|
| 1 | Aktivitetsstatus | Løbende og afsluttende status evaluering på aktiviteter | 01-12-2019 | 01-07-2100 |
| 2 | Jobmålsevaluering | Evaluering af borgerens Min plan jobmål | 01-12-2018 | 01-07-2100 |
EvaluationTypeIdentifier
Nye kodelisterværdier
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
|---|---|---|---|---|
| 1 | Afsluttende status evaluering | Afsluttende status evaluering på en aktivitet (Status på afsluttet indsats) | 01-07-2018 | 01-07-2100 |
| 2 | Løbende status evaluering | Løbende status evaluering på en aktivitet (Status på indsats undervejs i forløbet) | 01-07-2018 | 01-07-2100 |
| 3 | Ingen evaluering er relevant | Evaluering ikke relevant på dette element | 01-12-2018 | 01-07-2100 |
| 4 | Jobmålsevaluering | Evaluering på et jobmål | 01-07-2018 | 01-07-2100 |
OBS KSS bedes give input til navngivning, nu når vi har det oppe
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)
903.6.4 Som tester vil jeg i LSS kunne registrere løbende og afsluttende statusser for at mit testarbejde bliver mere effektivt
EvaluationService (Version 2) udstilles i LSS
Særlige krav til test
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
|---|---|---|
* 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.