Denne epic er en udvidelse af epic 903.5 og har således ophæng i LAB.

DS-2215 - Getting issue details... STATUS

OBS DETTE SKAL TILPASSES MED DE KORREKTE NUMRE NÅR EPICS OPRETTES I JIRA

Indholdsfortegnelse

Afgrænsning af epic

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

Denne epic er en opsamling i forhold til LAB og anvendelse af evalueringer (løbende og afsluttende status) på aktiviteter.

Løsningsmodellen

• Gøre metoder åben for at kunne lave status på andre forud definerede 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 simple 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 fortaget 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 scoop, 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

903.6.1 Som sagsbehandler vil jeg kunne registrere status på nye prædefinerede elementer, i denne kontekst også på borgerens jobmål

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 kun opdaterer 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 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 progrationsfelterne opdateret 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.

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 danne ikke en ny version af Min plan 

CodeListService (Version 5)

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.