Drivs fram genom ett innovationsprojekt för ekonomiskt bistånd
Arbetsmetoden som beskrivs här tillämpas i ett innovationsprojekt för automatiserad ärendeberedning och beslutsstöd vid ekonomiskt bistånd. Det är det andra projektet som följer det nya arbetssätt som först testades inom dokumenthantering — och syftar bland annat till att verifiera om metoden håller även för verksamhetsnära, myndighetsutövande utveckling.
Projektet kombinerar tre innovationsdagar där verksamhet och utvecklingsteam tillsammans verifierar problembild, MVP och öppna frågor, med en efterföljande tvåveckors utvecklingssprint. AI används som aktivt verktyg genom hela processen. Arbetsformen prövas nu en gång till i en kortare uppföljningssprint på en vecka (v.39, 21–25 september 2026), där tyngdpunkten ligger på att verifiera lösningen mot riktig data. Sidan dokumenterar arbetsformen steg för steg — som en levande instruktion.
Varför behövs ett nytt arbetssätt?
Rakel 2.0 är det andra projektet som tillämpar det nya arbetssättet — efter den första sprinten om dokumenthantering. Målet är att verifiera om metoden håller även för ett verksamhetsnära, myndighetsutövande område där regelverk, dataintegrationer och konsekvenser för enskilda spelar en helt annan roll än i en mer teknikdriven kontext.
Sundsvalls kommun har historiskt arbetat med traditionell agil utveckling inspirerad av stora ramverk som SAFe, utan att ha valt ett specifikt ramverk. Utvecklingsteamen har delats upp utefter kompetensområde — backend och frontend — med flera lager av roller mellan verksamheten och utvecklarna: projektledare, verksamhetsutvecklare, lösningsarkitekter och teamledare.
Verksamheten, som är ovan vid teknisk utveckling, har ofta svårt att formulera krav tidigt i processen. Kravbilden förändras löpande, vilket skapar osynk som leder till förseningar, budgetöverskridanden och resultat som inte möter verksamhetens faktiska behov.
- Projekt drar ut på tiden och håller inte budget
- Uppdelning i backend- och frontend-team skapar beroenden och väntetider
- Flera lager mellan verksamhet och utvecklare försvårar kommunikation
- Verksamheten har svårt att uttrycka krav tidigt — kravbilden ändras löpande
- Resultaten uppfyller inte verksamhetens faktiska behov
- Tvärfunktionella team som kan lösa hela uppgiften
- Direktkontakt mellan verksamhet och utvecklare — inga mellanlager
- Snabbare leveranscykler och kortare feedbackloopar
- Prototypdriven utveckling som validerar hypoteser tidigt
- AI som verktyg för att accelerera utvecklingsprocessen
Beslutsstöd med automatiserad ärendeberedning
Rakel 2.0 är inte ett system som fattar beslut automatiskt. Lösningen är ett beslutsstöd som preppar ärendet åt handläggaren — hämtar data, bygger normberäkning och lyfter flaggor utifrån regelverket. Handläggaren fattar beslutet; lösningen verkställer åtgärden efter bekräftelse.
- Hämtar data från verksamhetssystem och SSBTEK och bygger automatiskt en normberäkning.
- Lyfter flaggor till handläggaren utifrån regelverket — t.ex. inkomstavvikelser, utgifter över gränsvärden, personer som inte stämmer.
- Handläggaren granskar, justerar vid behov och fattar beslutet.
- Efter handläggarens bekräftelse utför lösningen åtgärden (beslut, utbetalning, kommunikation) mot verksamhetssystemet.
- Det enda stället lösningen styr är vägvalet: om ärendet inte uppfyller kriterierna för återansökan ruttas det till hantering som ny ansökan.
Projektets faser
Projektet är uppbyggt i fem faser: en förberedande fas där innovationsdagarna ingår, själva tvåveckors-sprinten, en utvärderingsfas, en kortare uppföljningssprint i september och slutligen fortsatt utveckling.
Förberedelser innan sprinten
Fas 0 omfattar både det tekniska förarbetet och innovationsdagarna. Fem moment skapar förutsättningarna för att teamet ska vara produktivt från dag ett av sprinten:
Prototyp och förarbete
Ett förslag på ansökningsformulär är framtaget (ej färdigt). Verksamheten har förberett sina önskemål kring frågor och logik i formuläret. Det finns en BPMN-process för flödet och en integration mot SSBTEK på plats. Det tekniska underlaget är på en nivå där sprinten kan ta vid och förfina mot färdig funktion.
Innovationsdagarna (5–7 maj 2026)
Tre dagar då verksamhet och utvecklingsteam tillsammans verifierade problembilden, tog fram MVP-lista och preciserade öppna frågor. Resultatet är direkta indata till sprinten — leverabler, beslut, MVP-krav och konkretiserade frågeställningar. Verksamheten höll i stora delar av dialogen och drev agendan.
Arkitektur- och teknikdialog
Övergripande dialog kring lösningsarkitektur och tekniska förutsättningar utifrån prototypen. Teamet alignar kring teknikstack, miljöer och övergripande designbeslut så att alla är redo att börja direkt.
Egen deploykedja till testbädd
Teamet säkerställs full access att själva deploya ändringar direkt till en dedikerad testbädd (sundsvall.dev). Inga beroenden till andra team, som exempelvis IT-produktion, för att löpande kunna leverera och verifiera förändringar under sprintens gång. Autonomi i hela kedjan är en förutsättning för sprintens tempo.
Bedöm verksamhetens involvering
Graden av verksamhetsinvolvering under sprinten måste bedömas utifrån vad som ska byggas — Rakel 2.0 är en verksamhetsnära funktion som kräver särskild domänkunskap, så nära dagligt samarbete med verksamhetsspecialister behövs. Stödet till verksamhetens förberedelse varierar dessutom med mognad och bör vara en explicit bedömning i Fas 0 — denna verksamhet klarade sig långt på eget bevåg efter inledande vägledning.
Vad ska vara på plats innan v.39
Retrospektivet efter den första sprinten pekade tydligt ut vad som behövde finnas på plats nästa gång. Punkterna nedan är den listan omsatt till förberedelser inför uppföljningssprinten, plus det som tillkommit sedan dess — en vecka har ingen buffert, så det som inte är klart innan dag 1 hinner inte lösas under sprinten.
Så mycket som möjligt konfigurerat — särskilt utbetalning
Verksamhetssystemet kommer inte att vara färdigkonfigurerat till v.39, och sprinten planeras utifrån det. Ambitionen är att så mycket som möjligt är konfigurerat innan start — inklusive utbetalningsdelarna, som ligger sist i flödet och är svårast att verifiera med mockad data. E2E-spåret riktas mot de delar som faktiskt är på plats; resten står kvar som byggt mot spec.
RPA-processen påbörjad
Återskrivningen till Lifecare sker initialt via RPA, och den processen behöver vara påbörjad innan sprinten — inte färdig, men så pass på plats att flödet kan köras och felsökas under veckan. Utan den stannar E2E-spåret vid beslutsunderlaget: allt fram till handläggarens bekräftelse går att verifiera, men inte att journal, bevakning, beslut och utbetalning faktiskt landar i verksamhetssystemet.
Besvarade öppna frågor
De öppna frågorna som blockerar färdig funktion — jämförelsetrösklar per inkomsttyp, hantering av avdrag, styrning av utbetalning — behöver svar från verksamheten innan sprinten börjar. Besluten är verksamhetens att fatta, och en vecka räcker inte för att både vänta in dem och bygga.
Helhetskarta och arkitekt nära
En karta över hur tjänsten hänger ihop med kringliggande system, och en arkitekt tillgänglig under veckan. Retron lyfte att avsaknaden av helhetsbild kostade tid i den första sprinten.
Testfall och testdata förberedda
E2E-scenarierna definierade och testpersonerna framtagna före start — se Funktionslista. Då går veckan till att köra, hitta fel och rätta, i stället för att sätta upp förutsättningarna.
Samma team plus verksamhetsexpertens efterföljare
Samma personer som i juni, på heltid — kontinuiteten är en förutsättning för att en vecka ska räcka. Till dem kommer de två personer som tar över verksamhetsexpertens roll, så att domänkunskapen förs vidare i arbetet under sprinten i stället för att lämnas i ett dokument. Utöver det en gemensam yta för att fånga frågor och beslut i tempot, och bättre koordination av parallella AI-sessioner.
Standup — sprintens dagliga nav
Varje dag genomförs en standup som fungerar som teamets gemensamma synkpunkt. Standupens syfte är tvådelat: att röja hinder för utvecklingen och att synka frågor och funderingar inom teamet och med verksamheten.
Genomgång av gårdagens utveckling
Teamet går igenom vad som gjorts sedan förra standupet — vad är klart, vad pågår, och var står vi i förhållande till sprintens mål?
Demo av ny funktionalitet
Om ny funktion har levererats körs en kort demo så att hela teamet ser framstegen och kan ge direkt feedback.
Frågor, hinder & synk
Öppen dialog där teammedlemmar lyfter blockeringar, frågor till verksamheten eller tekniska funderingar som behöver lösas för att arbetet ska flyta vidare.
Bärande principer för sprinten
Dessa principer vägleder teamets arbete genom hela sprinten.
Noll avstånd
Alla mellanlager mellan verksamhet och utveckling elimineras. Direkt dialog, direkt feedback.
Snabba leveranser
Korta cykler, dagliga leveranser och snabba feedbackloopar som fångar förändrade behov.
Tvärfunktionellt
Ett team som täcker alla kompetenser. Inga beroenden till andra team, ingen väntan.
AI-accelererat
AI används som verktyg i utvecklingen för att öka tempo och frigöra utvecklarnas kreativa kraft.
Hypotesdriven
Prototypen validerar en hypotes innan resurser investeras. Vi testar innan vi bygger klart.
Löpande anpassning
Processen utvecklas under sprinten. Vi lär oss och justerar dagligen.
Vad innebär det att delta i en innovationssprint?
Att delta i en innovationssprint är inte som vanligt projektarbete. Tempot är högre, avstånden kortare och förväntningarna annorlunda. Den här guiden beskriver det mindset och de beteenden som krävs av varje deltagare — oavsett roll — för att sprinten ska lyckas.
Mycket av det som beskrivs här kan kännas självklart. Men erfarenheten visar att det är just i gapet mellan att veta vad som krävs och att faktiskt agera därefter som de flesta sprintar fallerar. Läs med öppet sinne — inte för att lära dig nya saker, utan för att kalibrera ditt förhållningssätt.
En sprint lyckas inte för att teamet har rätt kompetens — den lyckas för att teamet har rätt inställning.
Ta ägarskap — inte instruktioner
Du är inte här för att utföra uppgifter. Du är här för att lösa ett problem.
I en sprint finns det ingen produktägare som talar om exakt vad du ska bygga. Det finns inget kravdokument som beskriver varje detalj. Istället finns det ett problem som behöver lösas, och du är en del av det team som ska lösa det.
Det innebär att du behöver förstå varför vi bygger det vi bygger — inte bara vad. Om du ser att något inte stämmer, att en lösning inte fungerar, eller att vi är på väg åt fel håll — då är det ditt ansvar att säga ifrån. Inte någon annans.
- Du ställer frågor när något är oklart — direkt, inte efter mötet
- Du föreslår alternativ om du ser en bättre väg
- Du tar initiativ att lösa problem utan att vänta på instruktioner
- Du hjälper teammedlemmar som fastnat, även om det inte är ditt ansvarsområde
- Väntar på att bli tilldelad arbete istället för att ta det
- Ser problem men säger inget — "det är inte mitt bord"
- Följer instruktioner blint trots att resultatet uppenbart blir fel
- Skjuter frågor framför sig — "jag tar det imorgon"
Kommunicera direkt och ofta
Kort avstånd kräver frekvent dialog. Tystnad är det största hindret.
En av sprintens viktigaste egenskaper är att avstånden mellan alla deltagare är minimala. Det finns inga mellanlager som filtrerar eller fördröjer information. Det betyder att du har direkt tillgång till alla — verksamheten, utvecklarna, alla i teamet.
Men kort avstånd är bara värdefullt om det faktiskt används. Om du sitter tyst med en fråga, om du inte delar framsteg eller om du undviker att ge direkt feedback — då förlorar vi sprintens viktigaste fördel.
Feedback ska ges direkt — inte sparas till nästa möte
I en sprint med dagliga leveranser hinner saker bli fel snabbt om feedback inte kommer i tid. Om du ser något som inte stämmer — i en demo, i en lösning, i ett beslut — säg det direkt. Att vara rak är inte oartigt. Att vänta tills det är för sent att ändra — det är problemet.
Det gäller alla riktningar: utvecklare mot verksamhet, verksamhet mot utvecklare, och kollegor sinsemellan. Sprinten lever på ärlig, omedelbar kommunikation.
Håll tempot — varje dag räknas
Nio arbetsdagar är inte mycket. Det som inte händer idag, händer kanske aldrig.
En tvåveckorssprint har ingen buffert. Det finns ingen "nästa sprint" att skjuta saker till. Det som inte görs idag minskar direkt vad vi kan åstadkomma totalt. Det betyder inte att du ska stressa — det betyder att du ska vara fokuserad och medveten om att din tid har direkt påverkan på resultatet.
Praktiskt innebär det: kom förberedd till standup. Lyft hinder direkt istället för att försöka lösa dem ensam i timmar. Fatta snabba beslut med tillräckligt bra information istället för att vänta på perfekt information som aldrig kommer.
Det perfekta är det godas fiende. Vi bygger för att lära — inte för att leverera en slutprodukt.
Omfamna förändring — det är meningen
Det vi bygger idag kommer att ändras imorgon. Och det är precis rätt.
I traditionellt projektarbete ses ändringar som ett problem — ett tecken på dålig planering eller otydliga krav. I en sprint är ändringar ett bevis på att processen fungerar. Vi bygger, vi testar, vi lär oss, och vi justerar. Det är själva poängen.
Det kräver att du släpper tanken på att "din del" ska vara perfekt och färdig. Var beredd på att det du byggt kan kastas om, att prioriteringar ändras och att lösningen utvecklas i en riktning du inte förutsåg. Det handlar inte om att ditt arbete var dåligt — det handlar om att vi vet mer nu än vi visste igår.
- "Vi lärde oss att det inte fungerade — bra, nu vet vi mer"
- "Verksamheten vill ha det annorlunda — då bygger vi om"
- "Jag hade fel om det här — tack för feedbacken"
- "Men vi bestämde ju redan att det skulle vara så här"
- "Det kan vi inte ändra nu — jag har redan byggt klart det"
- "Det borde verksamheten ha sagt från början"
Teamet framför individen
Din viktigaste uppgift är inte att vara bra på ditt — det är att göra teamet bättre.
I en innovationssprint arbetar alla tätt tillsammans. Det innebär att om du är klar med din uppgift men en kollega sitter fast, så är din nästa uppgift att hjälpa den kollegan. Det spelar ingen roll att det inte är "ditt område". Sprintens framgång mäts i vad teamet levererar — inte vad du personligen åstadkom.
Det innebär också att du behöver vara transparent med var du står. Att erkänna att du fastnat är inte en svaghet — det är att ge teamet möjlighet att lösa problemet snabbare. Att dölja problem för att "lösa det själv" är den dyraste misstaget i en sprint.
Alla roller är jämlika under sprinten
Under sprinten finns inga hierarkier. En verksamhetsspecialists observation väger lika tungt som en senior utvecklares tekniska bedömning. Den som har rätt information i stunden har mest att bidra med — oavsett titel. Det förhållningssättet kräver att alla lyssnar aktivt och respekterar varandras perspektiv.
Ha mod att vara obekväm
Tillväxt sker utanför komfortzonen — det gäller både produkten och dig.
En sprint pressar gränser. Du kommer att arbeta med människor du inte brukar samarbeta med. Du kommer att fatta beslut med ofullständig information. Du kommer att visa halvfärdigt arbete. Du kommer att få feedback som utmanar dina antaganden.
Allt detta är obekvämt. Men det är i det obehagliga som de verkliga genombrotten sker — både för produkten och för dig som deltagare. De sprint som producerar bäst resultat är de där deltagarna vågade vara osäkra, ställa dumma frågor och prova saker som kanske inte fungerade.
Den som aldrig visar halvfärdigt arbete lär sig aldrig om det var rätt väg. Våga visa, våga fråga, våga ändra dig.
Sex principer — ett mindset
Allt kokar ner till en enda sak: du är här för att bidra till att teamet löser ett verkligt problem på kortast möjliga tid. Det kräver ägarskap, rakhet, tempo, flexibilitet, laganda och mod.
Ägarskap
Förstå varför, inte bara vad. Ta ansvar för helheten.
Kommunikation
Prata direkt, ge feedback omedelbart, dölj ingenting.
Tempo
Varje dag räknas. Agera nu med tillräckligt bra information.
Förändring
Ändringar är bevis på framsteg. Omfamna dem.
Laganda
Teamets resultat är ditt resultat. Hjälp andra först.
Mod
Visa halvfärdigt. Ställ frågor. Våga ha fel.
Så rör sig ärendet genom lösningen
Schemat visar det tänkta flödet på hög nivå med datamängder per steg: inläsning → styrande vägval → datahämtning (verksamhetssystem, CareManagement, SSBTEK) → normberäkning → beslutsstöd och flaggor → beslut, utbetalning och kommunikation → effektuering → statusuppdatering. Återskrivning till verksamhetssystemet sker initialt via RPA, med processmotor/API som mål. Den kartan är från juni. Hur det fungerar i dag visas i kartan för återansökan längre ned.
Återansökan — vilka komponenter gör vad
Sedan september 2026 används ingen robot. Kartan nedan visar en återansökan från Mina sidor till effektuerad utbetalning, i simbanor per teknisk komponent. Varje anrop till Lifecare går via Lifecare-integratorn inne i kommunens nät. Det officiella API:et (FamilyCare) används där det räcker, främst i den automatiska beredningen och i kontrollerna. Det interna API:et, som Lifecares egen webbapp använder, används för det handläggaren gör och som det officiella inte stödjer: normberäkning, beslut, utbetalning, jobbstimulans, bevakningar, journal och dokument. CareManagement kontrollerar varje anrop, kopplar det som skapas till ärendet och loggar i åtkomstloggen.
Funktioner i Rakel 2.0
Nedan listas funktionerna grupperade i elva områden i samma ordning som ärendet behandlas — från ansökningsformulär till effektuering. Varje funktion har ett unikt ID med prefix för sitt område (FORM, IN, DATA, SSB, NORM, UTG, FLAG, BES, EFF, GUI, LOG). Funktionerna är konsoliderade från MVP-kraven, SSBTEK- och Rakel-regelverket, processkartan från innovationsdagarna samt regelverket för återansökan (september 2026), som tillförde nitton poster och skärpte ett tiotal beskrivningar.
Bockarna speglar vad som faktiskt levererats i koden — avläst direkt ur commit-historiken i repona, senast avstämt 24 september 2026. Motiveringarna omfattar även arbetet mellan sprintarna, som är sammanställt under Sprintdagboken. Varje avbockad funktion visar en kort motivering.
Listan är gemensam ryggrad för båda sprintarna. Funktioner märkta S2 är mål för uppföljningssprinten v.39 — märkningen byter till S2 ✓ när funktionen är klar. Sist ligger området E2E, som till skillnad från de övriga listar testscenarier snarare än funktioner: hela flödet körs igenom mot riktig data, och det är uppföljningssprintens huvudspår.
Funktionerna delas in i tre hinkar
Eftersom verksamhetssystemets IFO-delar inte är konfigurerade när sprinten genomförs (se Insikt 01) prioriterar vi funktionerna i tre hinkar utifrån vad som kan byggas och verifieras nu.
Kan byggas och verifieras med befintlig API-åtkomst. Här ligger sprintens primära leveranser.
Kan byggas men inte verifieras mot riktig data — verksamhetssystemet saknar testdata. Byggs mot API-specifikation med mockad data.
Kräver data eller integrationer som ännu inte finns. Tas inte upp i denna sprint.
-
FORM-01
Formulär för nyansökan✓ Levererat · nyansökan med formulärrevideringar + process
-
FORM-02
Formulär för återansökan✓ Levererat · återansökningsformulär byggt + granskat
-
FORM-03
Formulär för tilläggsansökan✓ Levererat · tilläggsansökan med normrutor + process
-
FORM-04
Skyddade personuppgifter — varning och spärrVarning på startsidan ("ska inte använda denna e-tjänst") och spärr mot att personer med skyddade personuppgifter ansöker. Komplement till IN-04c. Se Ö-01.✓ Levererat · spärr + ingen läcka av skyddad identitet
-
FORM-05
Startsida med viktig informationInformationssida innan ansökan: krav/rättigheter med länk till sundsvall.se, hur ansökan fungerar (BankID för sökande och medsökande), stickprovskontroll, korrekta uppgifter, meddelandefunktion och kontaktlänk.⚠ Byggt — informationssida före ansökan med länk till sundsvall.se, stickprovskontroll och kontaktlänk; verifierasS2
-
FORM-06
Civilstånd med BankID-signeringCivilståndsval i tre alternativ (ensamstående, gift/registrerad partner, sambo). Eventuell medsökande signerar med BankID i detta steg.⚠ Byggt — civilstånd + BankID-signering (mock)
-
FORM-07
Personuppgifter och notisinställningarVisa civilstånd samt personnummer och adress för sökande och ev. medsökande. Notisfråga "Hur vill du få notiser om din ansökan?" överst med val e-post/SMS (välj minst ett) och därefter kontaktfält, med info om att ändrade uppgifter slår igenom på Mina sidor.✓ Levererat · personuppgifter + notiskanal per person
-
FORM-08
Barnuppgifter med boendegradFråga om barn under 21 år som bor helt eller delvis i hemmet, med informationstext om vilka barn som ska anges. Per barn anges hur mycket barnet bor i hemmet under ansökningsmånaden, inkl. alternativet "Annat (ange antal dagar)" med dagfält 1–31.⚠ Byggt — barn/boendegrad, verifieras
-
FORM-09
Boende — villkorad logik och boendeformFråga om boendesituationen förändrats/kommer förändras under ansökningsmånaden. Vid oförändrat: ett sammanslaget fält för antal vuxna och barn i bostaden. Vid förändring: "Välj ny boendeform" ur fast lista. Rubriken "Boende" tas bort.⚠ Byggt — boendeform + villkorad logik, verifieras
-
FORM-10
Steg "Ansökan" med normvalDöp om steget "Ekonomi" till "Ansökan" och flytta ansökningsperioden hit. Normfråga "Vilken norm ansöker du bistånd för?" med val riksnorm eller annan norm.⚠ Byggt — steg Ansökan + normval, verifieras
-
FORM-11
Kostnadsposter att ansöka omEj obligatoriska kostnadsposter med infotext och beloppsfält (hyra, el, hemförsäkring, internet, a-kassa, fackavgift, resor, sjukresor/färdtjänst, läkarvård, medicin) samt "Övrigt bistånd" via rullista med fritext.✓ Levererat · kostnadsväljare med beloppsfält · internet borttaget 22 sep i kostnadstyperna, beslutstabellen och ansökningsformuläret enligt verksamhetens svar
-
FORM-12
Inkomster sedan senaste ansökanFråga med dynamisk text (du/ni) om inkomster/insättningar sedan senaste ansökan, med info om vilka inkomster som inte behöver redovisas, och omdöpta inkomsttyper i rullista.⚠ Byggt — inkomster sedan senaste ansökan, verifieras
-
FORM-13
Väntande ersättningarFråga om ansökt och väntar på beslut om ny ersättning från annan myndighet/organisation, med exempelinfo samt fält för vilken ersättning och namn på den som sökt.⚠ Byggt — frågan om väntande ersättningar med exempeltext och fält per ersättning i formuläret, och ett ja ger handläggaren varningen "Väntar på annan ersättning"; verifierasS2
-
FORM-14
TillgångarFråga om tillgångar som inte informerats om tidigare, med exempelinfo. Vid "Ja" väljs tillgångstyp inkl. "Annat", och dokumentkrav visas automatiskt.⚠ Byggt — tillgångstyper, verifieras
-
FORM-15
Planering på heltid"Vilken planering har [namn]?" per sökande/medsökande med info om heltidskrav. Omdöpta alternativ (sjukskriven, SFI-studerande, annan planering) och villkorade infotexter; sjukskriven utlöser dokumentkrav.✓ Levererat · planering per sökande/medsökande
-
FORM-16
Utbetalning"Hur vill ni ha eventuellt bistånd utbetalt?" (delas lika). Per sökande/medsökande: samma utbetalningssätt/konto som föregående ansökan, annars nytt utbetalningssätt, med fritext vid "Annat".⚠ Byggt — utbetalningssätt i sammanställning, verifieras
-
FORM-17
Vistelse och försäkranVistelseintyg om att bo i och huvudsakligen befinna sig i Sundsvall under perioden, uppdaterad försäkranstext (bidragsbrott, myndighetskontroll, återbetalning) och avslutande informationsruta om meddelandefunktionen.✓ Levererat · vistelseintyg + försäkran + signering
-
FORM-18
Dynamisk bifogat-/dokumentkravsmotorBilagor styrs av gjorda val: krävs underlag visas "Du behöver bifoga följande" med punktlista automatiskt, annars fråga om bilagor behövs (nej förifyllt). Dokumentkrav per boendeform, tillgångstyp, vid sjukskrivning, akut tandvård och vid nytt bankkonto för utbetalning (underlag som visar bankens namn, kontoinnehavare och kontonummer — personspecifik text per sökande/medsökande). Tillåtna format: docx, doc, jpeg, jpg, pdf, png.⚠ Byggt — bilage-/dokumentkravsmotor, verifieras
-
IN-01
Skapa händelse/aktualisering när ansökan inkommit⚠ Byggt — create-actualisation skapar aktualiseringen med typ, orsak, från vem och organisation enligt verksamhetens regelverk (21 sep). Svaret på den öppna frågan säger nu att Rakel ska stå som den som registrerat aktualiseringen medan ärendet fördelas till ärendets registrerade handläggare — den uppdelningen är inte byggd, handläggarfältet lämnas orört
-
IN-02
Hämta ansökan och bilagor från e-tjänsten✓ Levererat · hämtar ansökan + bilagor, samlad PDF
-
IN-03
Sök befintligt ärende✓ Levererat · gemensam ingång slår upp befintligt ärende
-
IN-04a
Styrande vägval — öppet ärende?Finns inget öppet ärende i systemet ruttas ansökan till hantering som ny ansökan.✓ Levererat · gemensam ingång ruttar till rätt flöde
-
IN-04b
Styrande vägval — huvudpersonÄr sökande och medsökande korrekt registrerade i systemet? Om nej, hantera som ny ansökan.⚠ Byggt — kontroll av huvudperson; ett testhushåll med medsökande finns nu i testmiljön, så kontrollen går att verifiera
-
IN-04c
Sekretessmarkering — hård stoppHanteras ej automatiskt. Se Ö-01.✓ Levererat · hård stopp vid sekretess, ingen statusläcka
-
IN-05
Arkivera ansökan och bilagorSlå ihop bilagor till samlad fil. Se Ö-02 för när detta sker.✓ Levererat · bilagor slås ihop till samlad fil · sedan 23 sep arkiverar processen både ansökan och bilagesammanställningen på aktualiseringen, och utfallet syns på ärendet — tidigare arkiverades ingenting automatiskt
-
IN-06
Processflöden per ansökningstypNy / åter / tillägg — varje flöde täcker hela kedjan inläsning → beslut → arkivering.⚠ Byggt — vägvalsreglerna kompletta för ny/åter/tillägg inkl. beslutskontinuitet (aug); verifieras mot riktig ärendehistorik
-
IN-07
Löpande statusuppdateringBåde lösning och handläggare uppdateras — t.ex. när mer information inväntas.✓ Levererat · notiser + status, läs-kvitton
-
DATA-01
Initial läsning från verksamhetssystemetPersonnummer, normberäkning (inkomster, utgifter, gemensamma hushållskostnader, personer/omfattning, norm), sekretessmarkering, senaste besluten med perioder.⚠ Byggt mot spec — FamilyCare-läsning med egen nyckel och RFC 3339-datum (aug); sedan 22 sep kan läsningen även gå via integratorn, vilket är vägen som fungerar utifrån kommunens nätverk. Verifieras mot riktig dataS2
-
DATA-02
Läsning från CareManagement: pågående återansökanMed perioder.✓ Levererat · läser pågående återansökan
-
DATA-03
Läsning från verksamhetssystemet: verkställighetAktualiseringar per person och datumintervall med typ, datum, orsak, handläggare, organisation och status, samt referens till insats, utredning och beslut. Personnummer stannar medvetet innanför integrationsgränsen.S2⚠ Byggt mot spec — listningen finns och används i pluklistan när ansökan arkiveras på en aktualisering; insatsens perioder kvarstår. Verksamhetens svar 21 sep säger att öppet ärende betyder insats eller utredning beroende på sammanhang, men värdemängden för aktualiseringens status är fortfarande obekräftad
-
DATA-04
Läsning från SSBTEK: inkomsterCSN, FK m.fl. samt ekonomiska beslut från Arbetsförmedlingen.⚠ Byggt mot spec — SSBTEK/FK-inkomster, verifierasS2
-
DATA-05
Läsning från CareManagement: inkomster + utgifterFrån ansökan.✓ Levererat · läser inkomster + utgifter från ansökan
-
DATA-06
Återskrivning till CareManagement: ny normberäkning✓ Levererat · skriver ny normberäkning till CareManagement
-
DATA-07
Återskrivning till verksamhetssystemetBevakningar/notiser, journal, dokument, beslut, utbetalning (vid normalkonto) — sker initialt via RPA, processmotor som mål.✓ Levererat · arkivering av dokument till vald Lifecare-aktualisering · sedan 22 sep registrerar roboten även utbetalningen i verksamhetssystemet och rapporterar tillbaka vad den fick · sedan 23 sep skriver handläggargränssnittet journalanteckningar, dokument, bevakningar, betalningsmottagare, utbetalningar och beslut direkt i verksamhetssystemet, och robotens motsvarande steg kan stängas av ett i taget · sedan 24 sep sparas även normberäkningen där, och robotintegrationen är avvecklad eftersom gränssnittet gör allt roboten gjorde
-
SSB-01
Läs ut samtliga inkomsterFörmån, alla delförmåner och beloppstyper.⚠ Byggt mot spec — inkomster från Försäkringskassan, Pensionsmyndigheten och CSN läses rätt ur SSBTEK:s underlag (21 sep). Verksamheten bekräftar samma dag att studiemedel läses från utbetalningsfliken och studiehjälp från CSN-fliken; verifieras mot riktig SSBTEK-data
-
SSB-02
Whitelist med godkända förmånerAllt utanför listan flaggas (visar förmån + delförmån + beloppstyp).⚠ Byggt mot spec — DMN-klassificering via inkomstregelverkets worker. Verksamhetens svar 21 sep vänder på principen: det som står på rålistan ska passera utan varning och bara det som saknas på listan varnas — de sex publicerade raderna som varnar för listade inkomster ska bort
-
SSB-03
Definiera ansöknings-, kontroll- och jämförelseperiodAnsökningsmånad = månaden ansökan avser, kontrollmånad = månaden innan, jämförelsemånad = månaden dessförinnan.⚠ Byggt mot spec — perioddefinition; verksamheten bekräftar 21 sep att utbetalningsdatumet styr vilken period en inkomst hör till — en utbetalning den 2 maj räknas till maj och följer med till normberäkningen för juni — och att regelverkets skrivning om månaden ersättningen avser inte gäller här; verifieras mot riktig dataS2
-
SSB-04
Överför inkomster i kontrollperiodenTill normberäkningen.⚠ Byggt mot spec — överför kontrollperiod. Sedan 24 sep slås en inkomsts kategori upp även på verksamhetssystemets namn — barnbidrag, dagersättning, PLV och a-kassa föll tidigare bort ur utkastet utan varning — och en inkomst som ändå inte går att föra över ger varningen "Inkomst kunde inte föras över". Verifieras
-
SSB-05
Överför inkomster i jämförelseperiodenSom ej redan överförts.⚠ Byggt mot spec — överför jämförelseperiod, verifieras
-
SSB-06
Undantag — inkomster som varken överförs eller flaggasHandikappersättning, extratillägg och bostadskostnad.⚠ Byggt mot spec — undantagsregler, verifieras
-
SSB-07
Undantag — inkomster som alltid flaggasTrots att de hanterats. Se Ö-03.✗ Utgår — verksamhetens svar 21 sep: inga varningar för inkomster som står på rålistan, så undantaget för inkomster som alltid flaggas finns inte längre
-
SSB-08
Generell jämförelsemotorSummera per förmån och jämför kontrollmånad mot jämförelsemånad — exakt jämförelse, ingen tröskel: samma summa ger ingen varning, olika summa ger varning. Saknad summa räknas som 0. Gäller barnbidrag, bostadsbidrag, underhållsstöd, studiehjälp, PM-Prel/PM, pension/SA/livräntor/vårdbidrag och barntillägg.⚠ Byggt — jämförelsemotorn som processmotor-worker (IncomeRulesEvaluator); fyra ersättningar undantogs från jämförelse enligt verksamhetens svar 21 sep, men grundregeln är fortfarande en 12 %-gräns och ska ändras till exakt jämförelse enligt regelverket för återansökan. Verksamheten bekräftar den exakta jämförelsen 21 sep; inkomstslaget för barntillägg är fortfarande obesvarat och utlovas i oktober, se Ö-18S2
-
SSB-09
Specialfall aktivitetsstöd/etableringsersättningFinns ekonomiskt beslut hos Arbetsförmedlingen? Kontrollera om 450 dagar är förbrukade, annars om utbetalning av aktivitetsstöd, utvecklingsersättning eller etableringsersättning saknas (varning 1) eller om antalet utbetalda dagar avviker från icke-röda dagar i kontrollperioden (varning 2). Kvittning läses ur SSBTEK och läggs till som inkomst utan varning.⚠ Byggt — dagkontrollen är byggd enligt verksamhetens beslut (23 sep): inget ekonomiskt beslut från Arbetsförmedlingen eller alla 450 dagar förbrukade ger ingen kontroll, ingen utbetalning i kontrollmånaden ger en varning, och annars jämförs uttagna dagar med icke-röda dagar. Processen skickar underlaget, men fälten är hämtade ur myndigheternas scheman och har ännu inte setts i ett riktigt SSBTEK-svar. Midsommarafton räknas som ersättningsdag sedan 24 sep, se Ö-16. Samtliga varningar ska visas samtidigt — beslutstabellerna ger i dag högst ett utfall per utvärderingS2
-
SSB-10
Specialfall föräldrapenningKontrollera uttagna dagar + glapp mellan perioder; flagga vid glapp eller saknad föregående månad.✗ Utgår — verksamheten tog bort kontrollen 21 sep: inkomsten ska inte finnas på rålistan, och beslutstabellen är borttagen ur det publicerade regelverket
-
SSB-11
Specialfall studiehjälpExtratillägg (855 kr) ska ej tas med; hantera uppehållsmånader. Se Ö-06.✓ Levererat · extratillägg känns igen på beloppet och tas inte med som inkomst, och säsongsregeln är byggd 22 sep: en separat SSBTEK-läsning bakåt till juni används enbart för studiehjälpsfråganS2
-
SSB-12
Jämför SSBTEK-inkomster mot normberäkningenSå inget dubbelförs.⚠ Byggt mot spec — jämför mot normberäkning, verifierasS2
-
SSB-13
Skapa nya inkomstslag för jämförelseAnnan inkomst, PLV, underhållsstöd, lön.⚠ Byggt mot spec — nya inkomstslag, verifieras
-
SSB-14
Inläsningsfel i SSBTEKVarna att hämtningen misslyckats och att nytt försök görs — och kör inte SSBTEK-regelverket förrän data går att lita på.⚠ Byggt — läsfelet varnas med verksamhetens egen formulering, inkomstreglerna körs inte och beräkningen lämnas orörd; varningen visas som banner i ärendehuvudet, går inte att kvittera och stängs när en senare körning lyckas (21 sep). Enligt svaret 21 sep ska hämtningen göras om var 30:e minut när den misslyckats — i dag görs nytt försök först vid nästa dygnskörning
-
SSB-15
Daglig omkörning av SSBTEK-kontrollenHämta om och kör regelverket på nytt varje dag, så att varningar försvinner när de inte längre är aktuella.✓ Levererat · processens dygnstimer går tillbaka till SSBTEK-hämtningen och kör hela regelverket på nytt varje dygn tills beslut fattas
-
SSB-16
Bortfallen inkomst sedan föregående månadFöregående månad i SSBTEK är facit — varna för förmån som fanns då men saknas nu, och ta bort varningen när den kommer tillbaka.✓ Levererat · varning per förmån som fanns i föregående månads SSBTEK-svar men saknas nu, och den stängs automatiskt när inkomsten kommer tillbaka (21 sep)
-
NORM-01
Skapa normberäkning från ansökanStart-/slutdatum, kopiera angivna inkomster och utgifter.✓ Levererat · normberäkning skapas från ansökan · sedan 24 sep skapas förslaget i verksamhetssystemet redan vid beredningen, när SSBTEK-underlaget är komplett, så att handläggaren möter det där
-
NORM-02
Hantera ofullständig vs. fullständig dataVid ofullständig: justera utifrån tillgängligt, flagga, schemalägg automatiskt nytt försök. Vid fullständig: justera utifrån all information och flagga eventuella avvikelser.✓ Levererat · fullständighetskoll + automatiskt nytt försök
-
NORM-03
StoppfunktionHandläggare kan "ta" ansökan så lösningen inte skriver över manuellt arbete.✓ Levererat · skrivskydd så manuellt arbete inte skrivs över
-
NORM-04
Kopiera underlag från föregående normberäkningNorm, familj och gemensamma kostnader hämtas från föregående normberäkning i Lifecare; inkomster, utgifter och levnadskostnader i övrigt från aktuell ansökan.⚠ Byggt — norm och familj kopieras från föregående normberäkning i verksamhetssystemet (24 sep). Roll och dagar går inte att läsa därifrån och tas från ansökan, och det som inte kan kopieras flaggas: en medlem som saknas i ansökan, en medlem i ansökan som saknas i förra beräkningen eller en medlem som bara ingick under en del av perioden. De gemensamma kostnaderna går inte att kopiera, eftersom hushållsstorleken inte kan läsas, så en kontroll varnar när förra beräkningen betalade dem för ett annat antal personer. Sedan 25 sep skickas hushållsstorleken med när förslaget skapas, som antalet personer om handläggaren inte valt en annan, så att de gemensamma kostnaderna räknas. Tidigare blev de 0. En hushållsstorlek som handläggaren ändrar sparas i verksamhetssystemet för kommande beräkningar. Dagarna ändras per person i Rakel, och verksamhetssystemet räknar beloppet
-
UTG-01
Generell utgiftsmotorJämför ansökt summa mot gränsvärdet och mot föregående månads godkända summa, sätt godkänt belopp och varna därefter. Täcker hyra, hemförsäkring, el, a-kassa, fackavgift, resor till planering/aktivitet, sjukresor/färdtjänst och övrigt bistånd — var och en med eget gränsvärde. Reglerna ligger som beslutstabeller i processmotorn.⚠ Byggt — utgiftsmotorn anropar en egen beslutstabell per kostnadstyp i processmotorn och faller tillbaka på ansökt belopp utan flagga när en tabell inte svarar; verifieras mot riktiga ärenden. Verksamheten bekräftar 21 sep att gränsvärdet tillsammans med föregående månads godkända summa är facit, och att de gamla procentreglerna för ändrad boendekostnad (10 och 25 procent) utgår
-
UTG-02
Specialfall medicin & läkarvårdMot gränsvärde utan föregående-jämförelse: inom gränsvärdet godkänns ansökt summa, över gränsvärdet godkänns 0 med varning. Egna gränsvärden för medicin respektive hälso- och sjukvård.✓ Levererat · egna beslutstabeller för medicin respektive hälso- och sjukvård — inom gränsvärdet godkänns ansökt summa, över det 0 kronor med varningS2
-
UTG-03
Övrigt biståndGränsvärdet är 0 kr, men föregående månads godkända summa kan ändå ge ett belopp — samma åttaradiga beslutstabell som övriga utgiftstyper.✓ Levererat · beslutstabell med alla åtta utfallen: gränsvärdet är 0 kr, men föregående månads godkända summa kan ändå ge ett belopp, alltid med varning för manuell kontrollS2
-
UTG-04
Implementera gränsvärdesmatrisenÅtta utfall per utgiftstyp: inom/över gränsvärde × föregående godkända saknas / är 0 / är >0, och i sista fallet om ansökt summa ligger under eller över den. Gränsvärdena är fastställda — hyra i sex nivåer efter ålder och antal barn, hemförsäkring i sju efter hushållsstorlek, och fasta belopp för el, a-kassa, fackavgift, medicin, hälso- och sjukvård, resor, sjukresor och övrigt bistånd. Se Ö-07.✓ Levererat · gränsvärdena ligger som beslutstabeller i processmotorn — hyra i sex nivåer efter ålder och barn, hemförsäkring i sju efter hushållsstorlek, fasta gränsvärden för övriga typer, och åtta utfall per utgiftstypS2
-
FLAG-01
Flagga utifrån ansökningsfrågorÄndrad boendesituation, utbetalningssätt, nya tillgångar, vistelse i kommunen m.fl.⚠ Byggt — beslutstabellen för ansökans svar ger varning direkt ur ett enskilt svar (17 regler); verifieras
-
FLAG-02
Flagga om månadsbeslut redan finnsFör perioden.⚠ Byggt — guard som fryser återansökan vid nyligt beslut, verifieras
-
FLAG-03
Flagga avvikelse i personerMellan ansökan och normberäkning/mall.⚠ Byggt — flaggar avvikelse i personer; varningen visar namn och roll i stället för person-id (21 sep), verifieras
-
FLAG-04
Flagga barn som inte bor heltid"Dubbelkolla inkomster". Se Ö-05.⚠ Byggt — när ansökan anger att ett barn inte bor heltid hos sökanden får handläggaren varningen "Barn bor inte heltid" med barnets namn. Varningen kommer från beslutstabellen för ansökans frågor. Barnets dagar i normberäkningen ändras per person i Rakel, och verksamhetssystemet räknar beloppet. VerifierasS2
-
FLAG-05
Visa ärenden markerade som återkravLäs och visa i gränssnittet.⚠ Byggt — ett beslut om bistånd mot återbetalning under de senaste 36 månaderna blir en varning på beslutsfliken med beslutstyp, datum, period och belopp (24 sep). Verksamhetssystemet har ingen egen post för återkrav och inga inbetalningar, så ett krav som betalats tillbaka eller efterskänkts listas ändå och handläggaren uppmanas kontrollera saldot där. Beslutstyperna är inte upplagda än, så matchningen på namn behöver bekräftas mot dem. Tidsfönstret går att ställa inS2
-
FLAG-06
Spegla bevakningar och notiserRen spegling utan logik — t.ex. tillfälligt uppehållstillstånd, barn som tar studenten.✓ Levererat · speglar bevakningar/notiser (Från Lifecare) · sedan 23 sep läses bevakningarna direkt från insatsen och kan skapas, ändras och tas bort i verksamhetssystemet
-
FLAG-07
Jämför ansökans inkomster mot föregående normberäkningLön och tjänstepension som fanns i föregående beräkning men inte uppgetts i ansökan, samt summaavvikelser på underhållsbidrag och hyresdel från barn eller inneboende.⚠ Byggt — varningstyperna i Drakel plus en beslutstabell som jämför varje inkomstslag i föregående normberäkning mot ansökan; verifieras
-
FLAG-08
Jämför hushåll och norm mot föregående normberäkningAntal personer i bostaden och vald norm — varna vid skillnad mot föregående beräkning.⚠ Byggt — HOUSEHOLD_CHANGE för hushållet, och en beslutstabell som jämför barn, hushållsstorlek och vald norm mot föregående beräkning; verifieras
-
BES-01
BeslutsförslagVisar förslag till beslut och utbetalningskonton. Standard beslutstyp 12:1, frastext och beslutsorsak från föregående beslut. Ändringsbart via rullistor. Handläggaren fattar beslutet, och vid bekräftelse registrerar lösningen det i verksamhetssystemet.✓ Levererat · beslutsförslag med fraser + alternativ · orsaker ur Lifecares egen katalog för både sökande och medsökande, och "Avvisning" borttaget som utfall (21 sep) · delavslag heter "Delvis bifall" i beslutsvalen enligt verksamhetens svar. Delvis bifall registreras sedan 24 sep med beslutstypen för bifall, eftersom en egen beslutstyp för delvis bifall saknas i verksamhetssystemet · det förra beslutet som förslaget utgår från väljs sedan 23 sep bara bland beslut om ekonomiskt bistånd · sedan 24 sep förväljs beslutstypen som förslag utifrån beslutsförslaget, räknat på den sparade normberäkningen i verksamhetssystemet, och orsaken förväljs från föregående beslut. Beslutet kan sparas skrivskyddat efter en bekräftelse
-
BES-02
UtbetalningSpeglar tidigare betalningsmottagare med konton och fördelningar, ändringsbart via rullista, kontering. Återskrivning till verksamhetssystemet gäller vid normalkonto. Se Ö-08, Ö-09, Ö-13.⚠ Byggt — utbetalningsformulär med betalsätt, OCR, kontering och bokföringsdatum; valbar betalningsmottagare ur klientens Lifecare-utbetalningar senaste tolv månaderna plus mottagare handläggaren lägger till manuellt, och registrerade utbetalningar sparas och listas (21 sep). Den 22 sep kom betalsätten ur verksamhetssystemets egen katalog, mottagarradens id följer med till roboten och roboten kan kvittera tillbaka vad verksamhetssystemet gjorde. Sedan 23 sep läses mottagare, saldo och registrerade utbetalningar direkt ur verksamhetssystemet, nya mottagare skapas där, och utbetalningarna registreras efter beslutet bara när saldot täcker beloppet. Sedan 24 sep registreras utbetalningen direkt från fliken med saldot och hela beloppet förifyllt, efter samma kontroller av saldo, betalsätt, månad, kontering, mottagare och hushåll. En likadan utbetalning som redan finns nekas, och Rakel behåller ingen kopia. Samma dag togs "Lägg till betalningsmottagare" bort ur Rakel, så handläggaren väljer bland mottagarna i verksamhetssystemet. Delad utbetalning och annat än normalkonto kvarstår, se Ö-08 och Ö-13S2
-
BES-03
KommunikationStandardmeddelandefunktion + dagens datum, ändringsbart (t.ex. digital brevlåda/papper). Vid bekräftelse utför lösningen aktiviteten.✓ Levererat · meddelande-/beslutskommunikation
-
BES-04
Meddelanden ska kunna arkiverasMellan handläggare och klient.✓ Levererat · meddelandehistorik kan arkiveras
-
BES-05
Varningar i beslutsflikenFöregående beslut i Lifecare var förskott på förmån, och delavslag när ansökt belopp inte godkänts i sin helhet — med belopp i varningstexten.⚠ Byggt — båda varningarna finns i beslutsförslaget. Förskott på förmån känns igen på beslutstypen enligt verksamhetens svar, och det förra beslutet väljs sedan 23 sep bara bland beslut om ekonomiskt bistånd — tidigare kunde ett beslut från en annan del av individ- och familjeomsorgen stå som förra beslutet, och då kunde varningen aldrig slå till. Verifieras när insatsen är konfigurerad i testmiljön
-
BES-06
Förslag på frastextVid bifall och delvis bifall föreslås frastext utifrån om hushållet har barn.✓ Levererat · frastextbibliotek med kategori och rubrik, inklusive "Bifall månad" och fullföljdshänvisning, som sedan 24 sep ligger i mallverktyget och redigeras på adminsidan. Vid bifall och delvis bifall fylls "Bifall månad" i, eller varianten med barn när barn eller umgängesbarn ingår i normberäkningen, med namn, belopp och period ur ärendet — en gång och bara i ett tomt beslutsmeddelande
-
BES-07
Varning om medsökande vid utbetalningFinns medsökande i ärendet — kontrollera om utbetalningen ska delas.⚠ Byggt — finns det medsökande i ärendet varnas handläggaren att kontrollera om utbetalningen ska delas, och sedan 24 sep stäms varningen av vid varje nattlig beredning i stället för när beslutssektionen godkänns, eftersom sektionsgodkännandena är borttagna. Verifieras mot testhushållet med medsökande
-
EFF-01
Läs om utbetalning är effektueradI verksamhetssystemet — inkl. datum och dokument som ska visas på Mina sidor.⚠ Byggt mot spec — sedan 23 sep kontrolleras exakt de utbetalningar beslutet registrerade, med sina id i verksamhetssystemet, i stället för vilken utbetalning som helst till personen för månaden. Sedan 24 sep läser kontrollen de utbetalningar som gränssnittet registrerat direkt i verksamhetssystemet via deras kopplade id, och annars ärendets egen insats och månad. Skälet när en utbetalning inte räknas som genomförd syns i processmotorn. Verifieras
-
EFF-02
Polling-loopUpprepa kontroll tills utbetalning är effektuerad. Se Ö-14.⚠ Byggt — processen läser av utbetalningsstatus var femte minut tills den är effektuerad. Har utbetalningen väntat mer än tre arbetsdagar efter beslutet aviseras ärendets handläggare en gång, men ärendet stängs aldrig på det (23 sep). Se Ö-14S2
-
EFF-03
Uppdatera ärendestatus i CareManagementNär effektuering bekräftats.✓ Levererat · uppdaterar ärendestatus + avsluta ärende
-
GUI-01
SSBTEK-knapp för manuell dubbelkollSpeglar befintlig mikrotjänst.S2✓ Levererat · "Hämta från SSBTEK" öppnar ärendets SSBTEK-sida i en ny flik, med betalningarna från Försäkringskassan, Pensionsmyndigheten och a-kassan per månad och utfällbara delförmåner, eller i en panel längst ner på ärendet om handläggaren valt det under Inställningar (24 sep). Läsningen är knuten till ärendets sökande eller medsökande och loggas i åtkomstloggen, och personnummer, namn och adresser i myndigheternas svar lämnar aldrig backend
-
GUI-02
Handläggare kan ändra i normberäkningenÄndringar skrivs tillbaka till verksamhetssystemet.✓ Levererat · handläggare redigerar normberäkningen inline · sedan 24 sep läses och ändras beräkningen direkt i verksamhetssystemet efter första sparningen, med dagar och normintervall per person, och verksamhetssystemet räknar beloppen. En beräkning som sparats som slutlig efter en bekräftelse är låst
-
GUI-03
Dokumentvisning på Mina sidorTaggning av dokument skrivs till administrationsverktyg och verksamhetssystem; dokumenten hämtas tillbaka för visning.⚠ Byggt — Dokument-flik; Mina sidor-visning väntar Ö-15S2
-
GUI-04
Markera meddelanden som hanteradeFiltret i översikten byter från olästa till ohanterade meddelanden.⚠ Byggt — notisen har fått "hanterad" som egen status vid sidan av läst, med eget filter i API:t (22 sep); översiktens filter byter först när gränssnittet går över
-
GUI-05
Migrerad PDF-journal i dokumentationsflikenDen historiska journalen ska gå att läsa i Drakel.⚠ Byggt — en knapp överst i journalen öppnar den migrerade journalen som PDF i en ny flik (24 sep). Den migrerade journalen ska få ett fast namn vid migreringen, så att den kan kännas igen och alltid visas. Tills den finns i verksamhetssystemet visas en testfil. Verifieras
-
GUI-06
Sökfunktion i journalen✓ Levererat · journal- och dokumentflikarna visar varje posts text direkt i listan och har en sökruta som filtrerar på rubrik, typ, akt, handläggare och text (23 sep). Hur långt bakåt journalen ska läsas är inte beslutat
-
GUI-07
Bred sökfunktion i översiktenKlient, ärendenummer, handläggare och status.✓ Levererat · egen Sök-vy (21 sep) med fritextsök på ärendenummer och sökande plus filter på status och handläggare
-
GUI-08
Kolumner och rensning i översiktenFastställda kolumner med hela texten synlig; prioritet och senaste aktivitet tas bort.✓ Levererat · prioritet och senaste aktivitet borttagna, och ärende- och sökandekolumnerna bryter texten i stället för att klippa den (21 sep)
-
GUI-09
Medhandläggare och aviseringarFler än en handläggare per ärende, med avisering — alltid minst en handläggare.⚠ Byggt — notispanel, aviseringar och tilldelning av handläggare finns. Sedan 23 sep går det i API:t att lägga till och ta bort medhandläggare på ett ärende, och aviseringarna syns då även för dem; gränssnittet för det kvarstår
-
GUI-10
Bevakningar alltid utfälldaMed antalet tydligt färgmarkerat.✓ Levererat · bevakningarna är utfällda från start och antalet visas i varningsfärg när något behöver åtgärdas (21 sep)
-
GUI-11
Skicka-knapp med dokument från Lifecare och DrakelMina sidor, meddelandefunktion och brev i samma dialog — redigerbar text och bifogade filer hämtade direkt, utan mellanlagring.⚠ Byggt — "Skicka beräkning och beslut" skickar beslutet som meddelande i ärendet eller som brev, med ett förslag till meddelande som går att redigera. Beslut och normberäkning bifogas från början som verksamhetssystemets egna utskrifter, och egna PDF-filer går att lägga till (25 sep). Digital brevlåda är borttagen, och Mina sidor sparas som val men skickas inte än. Sedan 28 sep går sökandens lagrade PDF:er i verksamhetssystemet att bifoga; textdokument och blanketter kvarstår
-
GUI-12
BankID-signering av båda sökandeEn loggar in med BankID, den andra godkänner hämtningen med BankID.✗ Utgår — beslut 21 sep: sökande och medsökande signerar i samma steg som i dag, och stöd för att signera vid olika tillfällen byggs inte nu. Tas upp igen om det visar sig bli ett problem i drift
-
GUI-13
Ansöknings-PDF med hjälptexter och ihopslagna bilagorVisningen i Drakel: PDF:en innehåller alla hjälptexter och bilagorna visas ihopslaget.⚠ Byggt — Bilagor-fliken visar ärendets bilagor och filer från meddelanden i en enda lista (21 sep). Ansöknings-PDF:en visas i Drakel som sammanställning och följer sedan 25 sep e-ansökan, med de informations- och hjälptexter som verksamhetens granskning saknade, en bilagedel utifrån svaren och kommunens brevmall. Verifieras
-
LOG-01
Händelselogg per ärendeVarje läsning och ändring i ett ärende loggas med vem som gjorde den.✓ Levererat · varje ärendeanrop skriver en rad med den anropande handläggaren, läsningar inräknade · sedan 23 sep även läsningar och skrivningar som gränssnittet gör direkt i verksamhetssystemet, och en läsning som inte kan loggas lämnas inte ut · sedan 24 sep även den manuella SSBTEK-läsningen, som nu är knuten till ett ärende
-
LOG-02
Uppföljning per handläggareSök fram vad en handläggare har läst och ändrat över alla ärenden, inte bara inom ett.✓ Levererat · egen listning i API:t med totalsumma, så en avkortad sida inte kan läsas som hela svaret, och en egen sida i Drakels administration (22 sep)
-
LOG-03
Loggning av sökträffarEn sökning ska inte lämna de träffade ärendena ospårade.✓ Levererat · en rad per träff sökningen gav; tidigare loggades listningar inte alls (22 sep)
-
LOG-04
Administration av mallar och frastexterSkapa, ändra och ta bort de mallar och frastexter handläggarna väljer bland för journalanteckning och dokument.✓ Levererat · egen administrationssida med flikar för de fyra sorterna, mallarna taggade så att bara Drakels egna visas (22 sep)
-
LOG-05
Behörighet per uppdragAtt underhålla mallar och att följa upp vem som läst vilket ärende är två olika uppdrag och ska gå att ge var för sig.✓ Levererat · var sin AD-grupp och var sin rättighet, oberoende av varandra (22 sep)
-
E2E-01
Ny ansökan från Mina sidorAnsökan skickas in, ärendet skapas och bereds automatiskt fram till handläggarens beslutsunderlag.S2
-
E2E-02
Återansökan med förifyllda uppgifterStyrande vägval träffar rätt och uppgifter från senaste beslut följer med in i formuläret.S2
-
E2E-03
Tilläggsansökan på öppet ärendeVägvalet ger tilläggsansökan och ärendet kopplas till rätt öppet ärende.S2
-
E2E-04
Sekretessmarkerad sökandeHårt stopp — ingen automatisk beredning sker, ärendet lyfts för manuell hantering.S2
-
E2E-05
SSBTEK-hämtning mot riktig dataInkomster hämtas skarpt och kontroll- respektive jämförelseperiod tillämpas korrekt.S2
-
E2E-06
Inkomstförändring över tröskelFörändringen upptäcks och lyfts som flagga till handläggaren — inget beslut fattas automatiskt.S2
-
E2E-07
Normberäkning stäms av mot verksamhetssystemetLösningens beräkning jämförs post för post med verksamhetssystemets egen beräkning.S2
-
E2E-08
Beslut och utbetalning skrivs tillbakaEfter handläggarens bekräftelse skrivs journal, bevakning, dokument, beslut och utbetalning till Lifecare.S2
-
E2E-09
Beslutet meddelas klientenMina sidor, digital brevlåda och brev — varje kanal oberoende, misslyckad kanal rapporteras.S2
-
E2E-10
Avslag och delavslagBeslutet formuleras med fullföljdshänvisning och kommuniceras på samma sätt som ett bifall.S2
-
E2E-11
Effektuering av utbetalningUtbetalningen följs upp och ärendets status uppdateras när den är effektuerad.S2
-
E2E-12
Regressionssvep av hela flödetSamtliga scenarier ovan körs igenom efter deploy för att fånga sidoeffekter.S2
Öppna frågor — 15 uppgifter
Frågor som identifierades under innovationsdagarna och som behöver besvaras innan respektive funktion kan byggas färdig. Presenteras som uppgifter att lösa, inte som osäkerheter. Regelverket för återansökan (september 2026) besvarar tre av dem helt och fyra delvis — motiveringen visar vad svaret blev.
-
Ö-01
Skilj på ruttning till ny ansökan och hård stopp vid sekretessBerör IN-04.
-
Ö-02
När ska bilagor slås ihop till samlad fil?Vid inskickning eller arkivering. Berör IN-05.
-
Ö-03
Hantera elstöd och skatteåterbäringSka de alltid flaggas eftersom de inte ser överförda ut? Berör SSB-07.✓ Besvarad · nej — inga varningar för inkomster som står på rålistan, så elstöd och skattekontouppgift varnas inte längre (21 sep)
-
Ö-04
Procentsatser och riktning för jämförelsetrösklarPer inkomsttyp. Blockerar SSB-08.✓ Besvarad · regelverket för återansökan: exakt summajämförelse per förmån, inga trösklar
-
Ö-05
Barn som bor deltid — halva inkomsterDefiniera hur lösningen ska känna till detta. Berör SSB-08 och FLAG-04.✓ Besvarad · hämtas från ansökningsfrågan — heltid / halvtid (16 dagar) / annat, jämförs mot dagar i föregående normberäkning
-
Ö-06
Studiestöd via uppehållsregelverk eller manuell flagga?Berör SSB-11.✓ Besvarad · uppehållsregelverket, inte en manuell flagga — frågan ställs längre bakåt i tiden enbart för studiehjälp, utan att vidga den ordinarie hämtningen (22 sep)
-
Ö-07
Hantera "avdrag soc" på bostadsbidrag och PLVHur ska detta flaggas? Berör UTG-04 och SSB-08.
-
Ö-08
Utbetalning — styrning på datum, uppdelning, OCR-fakturorBerör BES-02.⚠ Delvis · utbetalningsdatum den 27:e med vardagen innan vid helg, och enligt verksamhetens svar gäller det även röda dagar — kalendern är nu definierad i Ö-16. Flera utbetalningar ska gå; OCR och räkning finns som betalsätt i formuläret, men styrningen av uppdelade utbetalningar kvarstår
-
Ö-09
Förval av betalningsmottagare i verksamhetssystemetBekräfta om det går. Berör BES-02.✓ Besvarad · samma mottagare som föregående, med rullista över alla på klienten i Lifecare. Nya läggs upp i Lifecare och syns direkt i Rakel, eftersom mottagarna läses därifrån sedan 23 sep
-
Ö-10
Preliminär kontra definitiv skattAvstämning med Försäkringskassan krävs. Berör SSB-08.⚠ Delvis · PM-Prel och PM hanteras som en gemensam post i jämförelsen; avstämning med Försäkringskassan kvarstår
-
Ö-11
Kvittning och utmätning på dagersättningarBerör SSB-09.⚠ Delvis · kvittning läses ur SSBTEK och läggs till som inkomst utan varning; utmätning kvarstår
-
Ö-12
Karensavdrag och rehabersättning på sjukpenningBerör SSB-09.
-
Ö-13
Utbetalning till annat än normalkontoBerör BES-02 och DATA-07.
-
Ö-14
Pollingintervall och timeout för effektuerad utbetalningBerör EFF-02.✓ Besvarad · intervallet är fem minuter, och en utbetalning som väntat mer än tre arbetsdagar efter beslutet räknas som försenad och aviseras till handläggaren (23 sep). Ingen gräns stänger ärendet
-
Ö-15
Hur ska beslut meddelas och visas för klienten?Ska handläggaren manuellt ladda upp beslut och infodokument i meddelandeflödet, eller kan det ske automatiskt? Berör BES-03 och GUI-03.
-
Ö-16
Vilken helgdagskalender gäller för icke-röda dagar?Berör SSB-09 och Ö-08.✓ Besvarad · icke-röda dagar är vardagar måndag–fredag minus de allmänna helgdagar som infaller på vardag. Julafton, nyårsafton och midsommarafton räknas med, eftersom ersättning generellt betalas för dem — midsommarafton enligt verksamhetens besked 23 sep, där en riktig utbetalning för hela juni gällde 22 dagar. Samma kalender gäller utbetalningsdatumet, se Ö-08
-
Ö-17
Betalsättens värdemängd, fält och bokföringsdatumBerör BES-02.⚠ Delvis · värdemängden för betalsätt är inläst ur verksamhetssystemets katalog 22 sep och styr vilka fält som öppnas, men vad bokföringsdatum styr är fortfarande obesvarat
-
Ö-18
Vilket inkomstslag hör barntillägg till?SSBTEK-namn och inkomstslag i normberäkningen. Berör SSB-08.✗ Obesvarad · ny inkomst från oktober 2026 — verksamheten återkommer (21 sep) · tills dess ger inkomsten varningen "Inkomst kunde inte föras över", liksom studiemedel, studiebidrag och elstöd (24 sep)
-
Ö-19
Vem står som beslutsfattare vid registrering?Berör BES-01 och DATA-07.⚠ Delvis · beslutet fattas av handläggaren och handläggaren ska stå som beslutsfattare, men alla handläggare är ännu inte upplagda i verksamhetssystemets lista över beslutsfattare. Verksamheten svarar att Rakels eget konto får stå så länge — det måste ändras innan lösningen används skarpt · i koden står handläggarens eget konto som beslutsfattare, med ett testkonto som reserv i testmiljön (23 sep)
Lärdomar från innovationsdagarna
Rakel 2.0 är det andra projektet att tillämpa det nya arbetssättet. Under innovationsdagarna 5–7 maj 2026 framkom två centrala insikter som styr hur sprinten genomförs och hur arbetssättet behöver justeras framåt.
Verksamhetssystemets IFO-delar är ännu inte konfigurerade och saknar all data när sprinten genomförs. Det skulle kunna tala för att skjuta upp sprinten tills datan finns på plats — men vi väljer ändå att köra. Skälet är att verksamhetens nyckelkompetens — en och samma person som både är lösningsförvaltare och processexpert — går på föräldraledighet efter sommaren. Den domänkunskapen är inte ersättningsbar och vi vill ta tillvara den medan den finns tillgänglig.
Strategin blir därför att bygga mot API-specifikation med mockad data så långt det går nu, och verifiera mot riktig data när systemet är konfigurerat. Eftersom återskrivningen till verksamhetssystemet dessutom initialt sker via RPA — med processmotor/API som mål — får integrationen två olika "verifieringspunkter": en mot RPA-flödet och en mot framtida API.
Den uppenbara risken är att vi bygger något som inte håller mot verkligheten. För att hantera det isolerar vi integrationerna så att mocken enkelt kan bytas mot riktig data, och dokumenterar tydligt vad som är verifierat kontra byggt-mot-spec.
Bygg mot spec, isolera integrationerna så mock enkelt kan bytas mot riktig data, och dokumentera tydligt vad som är verifierat kontra byggt-mot-spec. Planera in verifieringsfönster i Fas 3 när verksamhetssystemet är konfigurerat.
Innovationsdagarnas plan var att verksamheten skulle hålla i förmiddagen dag 1 och att utvecklingsteamet sedan tog över. Det som faktiskt hände var att verksamheten höll i hela dag 1 — och drev både dialogen och agendan långt in på dag 2. Det blev formatets största framgångsfaktor: när verksamheten själv äger problembilden och leder genomgången skapas en helt annan precision i kraven än när tekniken översätter åt dem.
Insikten är samtidigt att stödet till verksamhetens förberedelse varierar med mognad. Denna verksamhet klarade sig långt på eget bevåg efter en inledande vägledning. En annan verksamhet hade behövt betydligt mer hjälp för att nå samma utgångsläge. Det betyder att vi inte kan ha en standardmall för förberedelsestöd — det måste vara en explicit bedömning i Fas 0 av varje sprint.
Praktiskt betyder det att rollen processledning av innovationsdagarna behöver ha utrymme att också vara tyst när verksamheten driver — och samtidigt kunna gå in och stötta mer aktivt när det behövs. En obalanserad förberedelse syns direkt: lägre engagemang, otydligare problembild, sämre MVP-lista.
Inkludera bedömning av förberedelsestöd till verksamheten som ett uttalat moment i Fas 0-processen för kommande sprintar. Avsätt en initial dialog där processledningen bedömer verksamhetens mognad och kalibrerar stödet därefter.
Sprintens dag-för-dag-logg
Loggen fördes dag för dag under tvåveckorssprinten v.25–26 (15–26 juni 2026) och innehåller anteckningar från standup, möten, beslut och faktisk utveckling i koden — som en levande logg och framtida referens.
Så fördes loggen: Efter varje standup lämnade processledningen anteckningar som kompletterades med commit-historik från sprintens kodrepon. Samma arbetssätt används i uppföljningssprinten v.39.
Standup
Verksamhetsexperten hade gått igenom formulärutkastet för återansökan och identifierat 24 feedbackpunkter. Hur kostnader och planering bäst ska fyllas i är fortsatt oklart — möte med UX bokades under dagen för att ta tag i det. Ändringar genomfördes i CareManagement.
Levererat i kod
api-service-caremanagement
- Integration mot Lifecare FamilyCare klar: lösningen kan nu läsa ärendehistorik och skriva tillbaka beslut och normberäkning
- Hela SSBTEK-inkomstpipelinen på plats: hämtar inkomster, tillämpar kontroll- och jämförelseperiod, flaggar förändringar över 12%
- FK-inkomster (Försäkringskassan) tillagda — täcker nu huvuddelen av EB-inkomster
- Gemensam ingång klar: bedömer om en ansökan ska bli ny-, åter- eller tilläggsansökan
web-app-drakel
- Kodkvalitetsinfrastruktur på plats: testramverk, ESLint, Prettier, CI-flöden och automatiska kontroller
- Alla beroenden uppgraderade — teknisk skuld betald dag 1
web-app-business-center
- Första version av ansökningsformuläret för ekonomiskt bistånd påbörjat
- Kopplingen mot CareManagement via Dokploy-miljön på plats
Standup
Formulärändringarna för återansökan visades och godkändes av verksamheten — särskilt sektionerna för inkomster, tillgångar och utgifter, framtagna med stöd av UX. Diskuterat: stoppfunktion för ärenden där sökande eller medsökande har skyddade personuppgifter (IN-04c) och en funktion som slår ihop uppladdade bilagor till en samlad fil för arkivering (IN-05). Planerat för dagen: handläggargränssnittet (Draken) och processlogiken i processmotorn påbörjas.
Levererat i kod
api-service-caremanagement
- Inkomstpipelinen kopplad hela vägen: SSBTEK-inkomster sätts ihop till en normberäkning som skrivs till Lifecare, med varningar för ohanterade inkomster och förändringar över 12%
- Beslutsstödet syns på ärendet: normberäkningens varningar skrivs som en rekommendation till handläggaren (markeras "kräver granskning" eller "ok")
- Bilagor slås ihop till en samlad PDF när en ansökan skapas — hanterar PDF, bilder och Word (.doc/.docx), med platshållarsida så sammanslagningen aldrig krockar (kopplar till IN-05)
- Meddelandefunktionen stödjer nu filbilagor
- Skyddade personuppgifter: har sökande eller medsökande skyddad identitet erbjuds ingen ansökan — personen hänvisas till handläggare, och statusen läcker inte ut via API:t (kopplar till FORM-04 / IN-04c)
- Formulärschemat exponeras via API per ansökningstyp (ny/åter/tillägg) så frontend kan bygga formuläret utan hårdkodning
- Notisinställningar per person: sökande och medsökande kan få egna notiser, med kontaktuppgifter från Mina sidor (kopplar till FORM-07)
- Återansökan förifyller bara hushållets barn — aldrig medsökande (verksamhetsfeedback)
- Integritet: personnummer tas bort från API:ts ytterkant — parter identifieras med partyId och slås upp internt endast mot Lifecare/SSBTEK
api-service-operaton
- Byggde processmotorns normberäkningssteg: anropar CareManagement och returnerar beräknings-id och varningar så processen kan rutta ärendet till handläggargranskning
- Lade till processteg för aktualisering/arkivering och utbetalning (tills vidare som stubbar tills systemstöden finns på plats)
- Förtydligade en bärande princip i koden: processmotorn utför inga utbetalningar själv — utbetalningarna sköts av en RPA-process i Lifecare som återkopplar till lösningen. Motorn läser bara av om utbetalningen är effektuerad och väntar tills den är klar
web-app-business-center
- Byggde ut återansökningsformuläret enligt verksamhetens feedback: sammanslagna steg, separat planering för sökande och medsökande, uppdaterade boendeformer (kopplar FORM-09, FORM-15)
- Sparar kontakt- och notisinställningar per person, sökande och medsökande (kopplar FORM-07)
- Bilagor: begränsning till tillåtna filtyper och tydligare hjälptexter om vad som ska bifogas (kopplar FORM-18)
- Validering av medsökandes personnummer och koppling mot det nya endpointet för att skapa ärende
- Löpande text-, informations- och stiljusteringar i formuläret
web-app-business-center
- Medborgarens ekonomiskt bistånd-ärenden visas nu på ärendesidan på Mina sidor
- Meddelanden i ärendet stödjer bilagor (ladda upp och ner)
- Översatte (i18n) kvarvarande texter i EB-flödet
web-app-drakel
- Påbörjade handläggargränssnittet (Draken): kvalitets- och testinfrastruktur på plats och beroenden uppdaterade
- Ny "Meddelanden"-flik i handläggarens ärendevy med filbilagor, omdesignad för att matcha Mina sidor
- Säkerhetshärdning: rate-limiting på inloggnings-/SAML-endpoints och borttagen kommandoinjektionsrisk i kodgenereringen (CodeQL-fynd åtgärdade)
- Diverse gränssnittsfixar (bl.a. fullbreddsfält i ärendevyn)
Standup
Sedan sist har handläggargränssnittet (Draken) byggts vidare — förhandsgranskning av bifogade filer i meddelanden är på plats — och BPMN-processen för återansökningar har påbörjats. Sammanställningar för bilagor visades, både bilagor från ansökan och bilagor som kommit via meddelanden, och UX ombads titta på den nya designen för meddelandevyn. Planerat för dagen: fortsatt logikutveckling i BPMN-processen samt att vy och logik för normberäkning påbörjas.
Levererat i kod
api-service-caremanagement
- Ärenden får nu ett läsbart ärendenummer i formatet EB-ÅÅMM#### med månadsvis löpnummer, härlett från verksamhetens namespace
- Ekonomiskt bistånd-processen startar automatiskt vid en inkommen återansökan, och sökandeparterna sparas på ärendet
- Normberäkningen delades upp i två steg: förbered (räknas fram utan att skrivas till Lifecare, kan göras om) och verkställ (skrivs först efter handläggarens beslut) — håller principen beslutsstöd ≠ automatiskt beslut tydlig
- Utkast till normberäkning kan redigeras med skydd mot oavsiktlig överskrivning
- Inkomstvarningar blev kvitterbara objekt, och normberäkningens fullständighet jämförs mot föregående månad
- Ny payment-status-endpoint som läser av utbetalningen i Lifecare (kopplar till RPA-återkopplingen)
- create-actualisation-endpoint som skapar aktualiseringen i Lifecare
- Bilagor taggas och klientens konversation slås automatiskt ihop till en PDF; bilder normaliseras till A4 vid sammanslagning (kopplar till IN-05)
api-service-operaton
- SSBTEK-regelverket flyttades ut ur CareManagement och in i processmotorn som en DMN-driven, in-process-evaluator som klassificerar inkomster
- Ny runtime-endpoint för beslutsutvärdering
- create-actualisation- och check-payment-status-stegen anropar nu CareManagement på riktigt (inte längre stubbar) — processen läser av Lifecare-utbetalningen
- Normberäknings-workern delades i förbered (loop) + verkställ (efter beslut), och rapporterar fullständighet
web-app-business-center
- Meddelanden i ärendet visas som chattbubblor med trådning, och man kan svara på och citera ett specifikt meddelande
- Nytt färgschema-val (ljust/mörkt/följ systemet) i användarmenyn
- Mjukare bubbelfärger och bättre kontrast i mörkt läge; trådar visas äldst först
web-app-business-center
- Sparar partsuppgifter när ärendet skapas, sätter rätt ärenderubrik och förbättrad validering av personnummer
- Formuläret scrollar till toppen vid sidbyte, plus löpande formulär- och stiljusteringar
web-app-drakel
- Handläggarens meddelandevy (Draken): trådad konversation med svar, chattbubblor som skiljer egna meddelanden från sökandens, datumavdelare och svenska relativa tidsstämplar
- Ärenden kan hämtas och ruttas via ärendenummer
- Bättre kontrast på bilagor, höjd takhöjd på konversationslistan samt kod- och lintstädning
web-app-drakel
- Anteckningar (notes) på ärendet, ärendedetaljer och uppdaterad ärendetabell
- Ny bilagor-flik för bilagor som kommit via meddelanden, med räknare, samt förhandsgranskning av bilagor och PDF
Standup
Måndagens standup efter midsommarhelgen summerade torsdagens arbete (sista dagen före helgen): normberäkningsfliken är klar med tillhörande backendlogik, meddelandevyns gränssnitt förbättrades, och flikar för beslut/godkännande av ärende respektive utbetalningar är på plats. Arbetet med att minska teknisk skuld fortsätter löpande. Planerat för dagen: sätta en plan för vecka 2 — större funktioner och penseldrag prioriteras tidigt i veckan, finslipning och detaljer senare.
Levererat i kod
api-service-caremanagement
- Beslut-fliken fick sitt API: beslut kan nu sparas med belopp, beslutsmeddelande, beslutsdatum och period i en spårbar rad. Tillåtna beslutsalternativ per ärendetyp exponeras (BIFALL/DELAVSLAG med belopp, AVSLAG/AVVISNING utan), och senaste rekommenderade beslut/belopp visas på EB-vyn — beslutsstöd, inte beslut: handläggaren beslutar
- Normberäkningen formades om för att spegla Lifecare FamilyCare-kontraktet fullt ut: Familj, Inkomster, Utgifter, Levnadskostnader i övrigt och Gemensamma kostnader
- Tresektionsmodell för normberäkningsutkastet (personer · inkomster · utgifter) där processens värde hålls åtskilt från handläggarens, med mjuk borttagning som överlever den dagliga SSBTEK-uppdateringen
- Per-sektion-kvittering: handläggaren kan godkänna varje sektion (beräkning · utbetalning · beslut) var för sig, med vem/när-stämpel
- Inkomstvarningar kan återöppnas till OPEN
- Bilagor: den sammanslagna klient-PDF:en taggas med konversationsursprung och den samlade bilagelistan kan filtreras på ursprung och avsändarroll
web-app-drakel
- Ny Beslut-flik i handläggarvyn, kopplad mot CareManagements besluts-API: alternativen styr listan, rekommendationen förifyller beslut/belopp/period/datum (0 kr vid avslag) och Spara skapar beslutet
- Ny Utbetalning-flik som läser av om Lifecare-utbetalningen för ansökningsmånaden är effektuerad — visar Utbetald (med datum) / Inte utbetald ännu / Status ej tillgänglig (kopplar till RPA-återkopplingen)
- Första versionen av normberäkningsvyn, plus varningsvisning, varningsplacering och partsuppgifter på ärendet
web-app-drakel
- Designjustering av meddelandevyn: vänsterställda meddelanden i full bredd, bilagor som kompakta chips och en mjukare bubbelfärg
Standup
Tisdagens standup gick igenom gårdagens (måndag 22 juni) utveckling. Teamet gick igenom vilka funktioner som under innovationsdagarna definierades som MVP, och vad som därmed ska prioriteras resten av veckan. Kvar att leverera för MVP: hantering av dokument i lösningen, arkivering av meddelanden och hantering av nyansökningar.
Levererat i kod
api-service-caremanagement
- Journalanteckningar (ärendejournal) fick fullt CRUD med skrivskyddslås på ärendet, och Typ-katalogen för anteckningar backas nu av den centrala metadata-lookupen
- Ny metadata-endpoint för EB-typer som matar både Mina sidor och Lifecare med etiketter, grupper och medborgar-flagga (citizenReportable) — komplett handläggar-uppsättning av typer plus handläggar-only Lifecare-typer, med grupper som stabila koder (HOUSING/WORK_AND_STUDIES/HEALTH/OTHER)
- Återansökan: DMN-styrd delta-flaggning som markerar förändringar i hushållsstorlek och boende sedan förra ansökan
- Bevakningar: datumbundna bevakningsobjekt med CRUD
- Regelverksvarningar för utgifter exponeras (skälighetsprövning + tak)
- Ansökt belopp kan anges när en normutgift skapas
- Teknisk skuld: EB/Lifecare-API:t normaliserat till engelsk namngivning, databasmigrering städad, och medborgarens inkomst/kostnads-kontrakt återställt för att laga Mina sidor
web-app-drakel
- Normberäkningen lyftes rejält: typ-dropdowns hämtas nu från metadata-katalogen, utgiftskolumnerna döptes till Förslag/Godkänt, effektivt belopp kan redigeras direkt, ansökt belopp anges på ny utgiftsrad, datumväljare på inkomstrader och bevarad scrollposition vid radborttagning
- Ny flik Journalanteckningar med modal för ny anteckning
- Ny Bevakningar-sektion i sidofältet
- Beslut/godkännande: sektionsvisa kvitteringar och avsluta ärende, samt lås av en sektions innehåll när den godkänts — handläggaren godkänner, det är beslutsstöd och inte automatiserat beslut
- Regelverksvarningar för utgifter visas i vyn, svenska rolletiketter med sökanden först, och bredare ärendevy (1400px)
web-app-business-center
- Medborgarens ansökan: koder för egendom/fordon/norm linjerades med caremanagements kontrakt
Standup
Onsdagens standup gick igenom gårdagens (tisdag 23 juni) utveckling — dagen gick bra. En omprioritering gjordes: arbetet med nyansökningar pausas och teamet gick i stället över till att bygga en notifieringsfunktion för meddelanden på ärenden som handläggaren är ansvarig för. Planerat för dagen: fortsatt prioriterad utveckling enligt den nya planen. Claes och Ebba tar en dialog med Sigrid direkt efter mötet.
Levererat i kod
api-service-caremanagement
- RPA-brygga: ny rpa-modul som lägger UiPath-köobjekt för de delar av Lifecare som saknar API (bevakningar, journal, dokument, beslut, utbetalning). CareManagement styr inte Lifecare direkt — en robot utför GUI-flödet utanför processen, idempotent och avstängd som standard. Beslutsstöd ≠ automatiserat beslut: robotjobbet triggas av processen/handläggaren, och en köhickup rullar aldrig tillbaka en redan committad Lifecare-skrivning
- Händelselogg: per-ärende vem/vad/när-logg över både läsningar och skrivningar, med läsbara beskrivningar, källa och aktör (X-Sent-By), filtrerbar — loggen överlever att ärendet tas bort
- Arkivering av meddelandehistorik (MVP): en konversation arkiveras först när sökanden skickat minst ett meddelande; handläggarens bilagor finns redan i Lifecare och dubbleras inte (markeras "finns i Lifecare"), och en periodrad (första–sista meddelandedatum) läggs till
- Oläst-räknare och läskvitton för meddelanden, åtskilt från händelseloggen och exkluderat från åtkomstloggen så att pollning inte flödar den
- Per-ärende badge-räknare för anteckningar, händelser, bevakningar och aktiva varningar
- Ärendeuppgifter: sökandens ansökningssammanställning bifogas som {ärendenummer}.pdf (ett CASE_DATA-original per ärende) vid EB-skapande; handläggare sätts på ärendet från sökandens Lifecare-uppgift
api-service-operaton
- Processmotorns fetch-lifecare-supplements-worker är inte längre en stub — den triggar via CareManagements nya RPA-endpoint en robot som hämtar de Lifecare-bara tilläggen (bevakningar/notiser, journal, dokument) som SSBTEK inte bär och skriver tillbaka dem på ärendet
- Workers taggas med X-Sent-By=operaton och normberäkningens prepare/commit pekar om mot CareManagements omdöpta /calculation-väg
web-app-drakel
- Ny Händelselogg-flik som flyttades till höger sidofält som kompakta kort, filtrerbar på källa; aktören stämplas via X-Sent-By
- Ärendeflikarna grupperade i två nivåer, med flik- och sidofältsdata som lazy-laddas vid behov och sidofältsräknare via ologgade count-endpoints
- Ny Dokument-flik; bilagor kan förhandsgranskas innan de skickas, och sökande/medsökande visas högst upp på ärendet
- "Från Lifecare"-ursprungschip på bevakningar; normberäkning kräver ansökt belopp på manuell utgiftsrad och en godkänd (låst) sektion förblir läsbar
web-app-business-center
- Medborgarens ansökan: sammanställningen konsolideras i de fem wizard-grupperna plus underskrift, och förhandsvisningen renderas från samma serializer som PDF:en (identiska frågor, svar och hjälptexter), med varje inkomst/tillgång/planeringspost som egen sektion med formulärets fältetiketter
- Ansökningssammanställningen (ärendeuppgifter) bifogas som PDF vid inskick — i formulärordning med numrerade grupper och X-Sent-By mot caremanagement
Standup
Torsdagens standup gick igenom gårdagens (onsdag 24 juni) utveckling. Sedan sist: frastexter samt besluts-, rubrik- och dokumentmallar på plats, förbättringar i normberäkningen, ihopslagning av menyer på ärendet, samt sparande och visning av den rådata (frågor och svar) som ärendet skapades med. Arbetet med nyansökan och tilläggsansökan har påbörjats. Planerat för dagen: fortsatt logik för tilläggsansökan, mindre förbättringar löpande, och en eventuell koppling mot Metan för att läsa ut sökandens barn och visa dem i nyansökan.
Levererat i kod
api-service-caremanagement
- Normberäkning kan nu skapas direkt från en nyansökan
- Automatisk tilldelning av handläggare via DMN-regel (Decision_defaultAssignee)
- Oföränderlig, återrenderbar snapshot av medborgarens ansökningsformulär — rådatan (frågor och svar) som ärendet skapades med sparas och kan visas igen
- Ansökt belopp på normutgift kan redigeras, och utkastsektionerna håller stabil radordning
- Notis vid inkommande meddelande även när ärendet ännu saknar handläggare
- Ärendet stämplas med tidpunkten för den senaste dagliga körningen
api-service-operaton
- Nytt processteg (worker) som skapar normberäkningen för nyansökansprocessen
web-app-drakel
- Mallar: mallstyrd dokumenteditor (ny Templating-tjänst), redigering i WYSIWYG-editor och dokumenttext som renderas som sanerad HTML i listan
- Beslut: beslutsmeddelande-editor med frasmallar, frastexter för bifall och en samlad "Alla"-kategori, enkelval i frastext-comboboxar
- Normberäkning: ansökt belopp redigerbart på utgiftsrader, inline-sparande (on-blur) med utkastrad för nya rader som håller sin plats via serverposition, och inkomstdatum skickas som date-time
- Flikar och menyer: "Meddelanden och bilagor" lyft till toppnivåflik och uppdelad i separata Meddelanden- och Bilagor-flikar, fliklayout per ansökningstyp (ny/tillägg/åter), och flikar förblir klickbara när en sektion godkänts
- Ansökningssnapshot renderas som ärendets sammanställning, med tydligare sammanställningstitlar för bilagor
- Notiser: handläggarens notiser listas i översikten, som kan filtreras på okvitterade notiser
- Omgenererade API-kontrakt mot caremanagement samt diverse mindre fixar
web-app-business-center
- Oföränderlig formulär-snapshot som speglar den bifogade PDF:en
- Justeringar i tilläggsformuläret och fix av personnummeranrop för sambo
Standup
Fredagens standup — sprintens sista dag — gick igenom gårdagens (torsdag 25 juni) utveckling: ändringar i nyansöknings- och tilläggsformuläret, inläsning av barn till sökande från Citizen, och vidareutvecklat regelverk för utgifter. Planerat för dagen: finslipning av gränssnittet, backend för jobbstimulans och eventuellt regelverk för ansökan. Sprinten avslutas med retrospektiv 10:00–11:30.
Levererat i kod
api-service-caremanagement
- Regelverk för utgifter (verksamhetens skälighetstabell): varje EB-utgiftstyp får nu sitt eget modellerbara regelträd (hyra, hemförsäkring, … övrigt bistånd) där godkänt belopp styrs av föregående månads godkända belopp och gränsvärdet styr varningstexten — ersätter den tidigare felkopplade regeln så att taken faktiskt slår till. Sökandens ålder, antal barn och hushållsstorlek matas in i bedömningen — beslutsstöd, inte beslut
- Återansökan-guard: när en sökande (eller medsökande) nyligen haft ett EB-ärende avslutat (konfigurerbart fönster, förvalt 30 dagar som platshållare tills antalet dagar bestämts med jurist) rekommenderas återansökan, och en ny ansökan fryses som "kräver manuell granskning" (ingen process/aktualisering startas) tills handläggaren öppnar den — då körs den som en vanlig återansökan
- Auto-start av nyansökan-processen för nya EB-ärenden — nu startar alla tre intagstyperna (nyansökan, återansökan, tillägg) sina processer automatiskt
- Lifecare-aktualiseringar: lista en persons aktualiseringar (personnummer-säker modell, pnr borttaget) och arkivera ett uppladdat dokument (t.ex. en tilläggsansökan) till en vald aktualisering
- Ärendelistan: sorterbart och sökbart sökandenamn; EB-statusar exponeras med svenska visningsnamn och livscykelordning, inmatade i den redigerbara metadata-katalogen
- Handläggarredigerat ansökt belopp på systemgenererade utgiftsrader bevaras över den dagliga uppdateringen
api-service-operaton
- Uppstädning: död update-errand-parameter-worker borttagen
web-app-business-center
- Nyansökningsformuläret reviderat (gäller bara nyansökan; återansökan/tillägg oförändrade): tolkfråga och boendesituation flyttade/omformulerade, "Vad avser ansökan?" och norm blev flerval, obligatorisk försörjnings-fritext, jobbsökande lägger automatiskt till planerad aktivitet + jobbansökningsrad, och egen referensdokumentlista för bilagor per sökande/medsökande
- Tilläggsformuläret: norm visas som utgiftsboxar med specifikation per norm, 80-teckens gräns + räknare på kostnadsspecifikationen, och hjälptexten "Sök endast" visas bara på nyansökan
- Barn till sökande: hämtar vårdnadsbarn från Citizen (custodychildren) för både sökande och medsökande, slås ihop med Lifecare-förifyllningen och dedupas i samma barnförslag (best-effort så en utebliven träff aldrig blockerar formuläret); åtkomstscope begärs bara för vårdnadsbarn
web-app-drakel
- Översikten körs nu helt server-side (RSQL-filter, sortering, paginering med rader per sida) med fyra vyer i sidofältet — Alla / Nya / Öppna / Avslutade — och en filterpanel med status/prioritet (flerval), borttagbara chips och olästa meddelanden. Ny Sökande-kolumn med serversortering och fritextsök på ärendenummer + sökandenamn; "Senaste aktivitet" visas i Idag/Igår-format
- Beslut: "Besluta och utbetala" renderar beslut-PDF:en, sparar den som DECISION-bilaga och skickar beslutet till valda kanaler (Mina sidor, digital brevlåda, brev) — varje kanal oberoende, misslyckade kanaler rapporteras; PDF:en visas i egen subflik och sparat beslutsmeddelande läses tillbaka i editorn med fullföljdshänvisning. Åtgärden visas bara på återansökan och när ärendet inte är avslutat
- Aktualisering: ansöknings-PDF:en kan arkiveras till en vald Lifecare-aktualisering, med aktualiserings-id i pluklistan
- Mallstyrda journalanteckningar i WYSIWYG-editorn; läsbarare form-snapshot (sektionskort, tvåkolumns fält); bredare beslutsfält med belopp-summaruta
Sprintens sista dag — ingen standup. Nedan dagens kodleverans inför slutdemo och retrospektiv.
Levererat i kod
api-service-caremanagement
- Ny läs-igenom-tjänst som serverar sökandens Lifecare-historik direkt till Draken: normberäkningar (full nedbrytning — header-summor samt inkomst-, utgifts-, särskild-utgift- och hushållsmedlemsrader), beslut (header + personer) och dokument (metadata + PDF-strömning); partyId slås upp till personnummer via citizen-tjänsten, med 24-månadersfönster som default
- Svensk lokalisering genomgående: notistyper/-undertyper, nya-meddelande-notiser, händelseloggens beskrivningar och EB-varningar fick svenska visningsnamn (plus enum-visningsnamn)
- Robusthet i EB-ansökningsinläsningen: tolererar skalärvärde där modellen väntar en lista (med tydligt parse-fel), accepterar 'request'-delen utan JSON-content-type, och errand-created-lyssnaren gör omförsök på MariaDB 11:s snapshot-isolation-race
web-app-business-center
- Fick medborgaransökans inskick att gå igenom mot caremanagement — byggde om multipart-anropet så 'request'-delen skickas som ren JSON i dokumenterat format, X-Sent-By i rätt format och normType som lista
- Barn till sökande återaktiverat via en scope:ad token (CitizenRelationAccess) som bara skickas på custodychildren-anropet, så barnförslagen ger data igen (best-effort — en utebliven träff blockerar aldrig inskicket)
web-app-drakel
- Finslipning av handläggargränssnittet: Alert-baserade varningar/status, godkänd-markering på flikar med grön alert, datumväljare i normberäkning och layoutjusteringar
- Delad och klickbar PDF-förhandsgranskning som fungerar även vid låst sektion, "Visa pdf" bredvid titeln och robustare normberäknings-PDF
- Översikten persisterar nu filter och sortering i en zustand-store (med hydration-guard)
Mellan sprintarna
Arbetet stannade inte när sprinten tog slut. Mellan 26 juni och uppföljningssprintens start den 21 september fortsatte utvecklingen i vanlig takt — utan sprintform, utan daglig standup och utan den täta verksamhetsdialogen. Den här sidan dokumenterades inte löpande under perioden; posterna nedan är sammanställda i efterhand ur commit-historiken, så att uppföljningssprintens utgångsläge blir rätt.
Varför det spelar roll: funktionslistan är avbockad per 24 juni. En del av det som står som byggt mot spec eller ej påbörjat har flyttat sig sedan dess — särskilt gemensam ingång och handläggargränssnittet.
Levererat i kod
api-service-operaton
- Drakel-branchen mergad till main (PR #22) — inkomstregelverket som Operaton-workers, 2 787 tillagda rader över 51 filer
- ClassifiedIncome infört, beslutsnyckeln tas som parameter på evaluate och payment-status-workern fick tydligare dokumentation och avgränsad sent-by-hantering
- Regressionstester för inkomsttolkning och varningar
Levererat i kod
api-service-caremanagement
- Hela Rakel-plattformen mergad till main (PR #12) — Spring Modulith-omstruktureringen tillsammans med alla nya moduler i samma PR, så att varje utbyggnadspunkt (ErrandTypeRegistry, StakeholderRoleRegistry, ProcessService, PDF-sammanslagningen över moduler) har en verklig konsument. 88 448 tillagda rader över 952 filer
- FamilyCare: datum skickas som RFC 3339 och användarkatalogen autentiseras med egen nyckel (PR #18)
- Belopp bärs som BigDecimal, create-requesten binds som typad POJO och de otrådade utkastberäkningarna är borttagna
- Gemensam ingång färdigställd (PR #22): tre regler saknades eller satt på fel kriterium. Tyngst vägde att beslutskontinuiteten saknades helt — bedömningen tittade aldrig på om föregående månader var beslutade, så en sökande vars senaste beslut var fem månader gammalt föreslogs återansökan trots att regelverket säger ny ansökan
Levererat i kod
web-app-drakel
- Backend och frontend följer den omarbetade CareManagement-plattformen och dess nya fält
- Svensk etikett för varningstypen förändrad boendekostnad
Periodens största enskilda leverans — gränssnittet ritat om enligt Rakel 2.0, cirka 3 500 tillagda rader över 86 filer i en PR, plus städning och språkstöd ovanpå.
Levererat i kod
web-app-drakel
- Nytt skal för handläggningsvyn: administrationsrad, meta-kort för ärendet, tilldelning och notiser i headern — status och prioritet brutna ut till egna moduler
- Nytt innehåll i ärendeflikarna: personkort, etikett/värde-par, läsbara tabeller, sektionsrubriker, bilagerader med filikoner och uppladdningsfält samt åtgärdsmeny per rad. Normberäkningen fick tabellbox och summabox
- Konversationsvy för meddelanden med formaterade meddelanden, och ny översiktssida enligt Rakel 2.0
- Lifecare-ursprung, jobbstimulans och sjukskrivningsperiod visas i ärendet; namn på sökande och medsökande hämtas från Citizen
- Gemensam AsyncContent för laddning, fel och tomt läge, och gemensam useServiceQuery för datahämtning — samma mönster i hela appen
- Gränssnittet på svenska och engelska med språkval i användarmenyn (104 filer)
- Död kod, mallrester från startern och backend-routes som frontend inte använder borttagna
Levererat i kod
RPA-Drakel
- Dokument hämtas per insats i stället för för hela klienten, och tjänsten väljs på titel i stället för att första träffen tas
- Content-hämtningen routas på dokumenttyp, gör omförsök utan hideRevisions och hoppar över typer som mottagaren ändå kastar
- Lifecare-beroendet pinnat till 0.0.1-alpha.10
- CLAUDE.md, onboarding-fil och offline-kontroller på plats i repot
web-app-business-center
Repot var aktivt under perioden, men allt arbete rörde andra tjänster — Draken, parkeringstillstånd, OpenE-utkast och SAML-härdning. Ansökningsformuläret för ekonomiskt bistånd står kvar där sprint 1 lämnade det.
Uppföljningssprintens dag-för-dag-logg
Uppföljningssprinten är en vecka lång — v.39, 21–25 september 2026, och pågår just nu. Loggen fylls i löpande under veckan med anteckningar från standup, beslut och faktisk utveckling i koden, på samma sätt som under den första sprinten.
Så uppdateras sidan: Efter varje standup lämnar processledningen anteckningar som kompletteras med commit-historik från sprintens kodrepon. Dagsinläggen nedan fylls på i takt med att veckan fortskrider.
Uppstart
Sprinten inleddes med ett kort uppstartsmöte. Sprintformatet gicks inte igenom på nytt — det sitter sedan i juni — så tiden lades på vilka som är med, var vi står och vad veckan ska handla om. Nya deltagare från verksamheten hälsades välkomna, bland dem de som tar över verksamhetsexpertens roll, och teamet gick igenom sina roller: processledning, backend och API, processmotor, RPA, UX, frontend och systemförvaltning. Standup hålls varje morgon hela veckan — vad som är gjort, vad som ska göras under dagen, och demo av det som går att visa.
Beslut om fortsättning har kommit från styrgruppen.
Läget vid start
Sprint 1 lämnade mycket av ansökningsformuläret och handläggningsdelarna på plats, men också en mängd öppna frågor. De två största begränsningarna då var att teamet saknade tillgång till verksamhetssystemet och att RPA inte var med — båda är annorlunda nu. Sedan juni har formuläret finslipats, koden städats, SSBTEK kommit på plats, RPA-processen påbörjats och utbetalningsdelen lagts in. Ett internt API ändrades under sommaren och tvingade fram en omarbetning, men grunden ska vara tillbaka, och backend och RPA-processen pratar bättre med varandra. Handläggargränssnittet är omgjort sedan förra sprinten. Regelverket för återansökan skickades in i torsdags och blir en bärande grund för veckan.
Hinder: vid uppstarten fungerade kopplingen mot SSBTEK bara i produktionsmiljön, inte i testmiljön. Senare under dagen gick det att läsa från test igen, så hindret ser ut att vara ur vägen och E2E-spåret kan köras mot testdata.
Fokus för veckan
Målet är att sätta de sista stora pusselbitarna snarare än att finslipa: regelverket, beräkningarna — inklusive hämtning av föregående beräkning — och utbetalningen. Utöver det end-to-end-tester, så att delarna går att se fungera tillsammans. Finslipning görs i mån av tid. Nyansökan bedöms kunna återanvända mycket från återansökan och har i stort sett inget eget regelverk.
Beslut
- BankID-signering behålls som den är. Idag måste sökande och medsökande signera i samma steg, annars sparas inte ansökan. Stöd för att signera vid olika tillfällen byggs inte nu — det tas om det visar sig bli ett verkligt problem i drift.
- Ansökningsdatum = datum för inskickandet. Det är alltid korrekt oavsett när i tiden signeringarna gjordes.
- Nyansökan kan hanteras manuellt tills vidare via e-tjänsten, om tiden inte räcker till.
- Arbetssättet för veckan: gå igenom regelverksdokumentet mot det som faktiskt är byggt, med AI som hjälp, för att se vad som finns och vad som saknas.
Levererat i kod
Koden följer standupens beslut. Normberäkningen skapas nu i verksamhetssystemet och redigeras där direkt från Rakel. Verksamhetssystemet räknar beloppen, också jobbstimulansen och beloppet för en person med färre dagar, och en beräkning som sparats som slutlig är låst. Utbetalningar registreras direkt, journal och dokument har fått två sparknappar och beslutet kan sparas skrivskyddat. Rakel behåller bara referenser till det som ligger i verksamhetssystemet — där finns facit. Robotintegrationen är avvecklad i backend och processmotorn, eftersom gränssnittet nu gör allt roboten gjorde. Enligt ett beslut 23 september tas roboten inte i produktion.
api-service-caremanagement
- Robotintegrationen är avvecklad, och inget i backend köar längre arbete åt en robot. Kopiorna av verksamhetssystemets journalanteckningar, dokument och bevakningar är raderade, eftersom gränssnittet läser dem direkt. Det som handläggaren själv skrivit i Rakel ligger kvar. Gränssnittet som processen hämtar hushållets personnummer från har bytt namn, och inget bär längre robotens namn
- Normberäkningen ägs av verksamhetssystemet. Gränssnittet sparar den där före beslutet, eftersom ett bifall tar sitt belopp ur beräkningen, och ärendet bär bara en referens till den. När beräkningen finns slutar den nattliga beredningen att skriva över utkastet. Varningarna som bygger på utkastet fryses, också den för ändrad boendekostnad
- Förslaget till normberäkning skapas i verksamhetssystemet redan vid beredningen, så att handläggaren möter det där och inte bara som ett utkast i Rakel. Det görs först när SSBTEK-underlaget är komplett, eftersom en beräkning som skapats den vägen inte går att uppdatera. Ett misslyckat försök görs om nästa natt, och processen stoppas aldrig
- Norm och familj kopieras från föregående normberäkning, som regelverket för återansökan säger. Roll och dagar går inte att läsa ur den tidigare beräkningen och tas därför från ansökan. Det som inte kan kopieras flaggas: en medlem som saknas i ansökan, en medlem i ansökan som saknas i förra beräkningen eller en medlem som bara ingick under en del av perioden. En norm som handläggaren valt skrivs inte längre över varje natt. Kontrollen av gemensamma hushållskostnader jämför nu med ansökans hushåll. Den gamla jämförelsen kunde aldrig slå till
- Beslutsförslagets utfall räknas på den sparade beräkningen i verksamhetssystemet, där norm och jobbstimulans tillämpas, och inte på Rakels uppskattning. Förslaget anger vilket underlag det vilar på, så att utfallet inte motsäger beloppet bredvid. Beslutsformuleringen kommer inte längre från backend
- Slutförandet kräver det som faktiskt ska finnas: ett registrerat beslut vid alla utfall och en sparad normberäkning vid bifall och delvis bifall. Ett avslag med kopplade utbetalningar nekas. Vid beslutet raderas utkastet till normberäkning om beräkningen finns i verksamhetssystemet, så att hushållets inkomster och utgifter inte lagras två gånger
- Utbetalningar lagras inte längre i Rakel. Gränssnittet registrerar dem direkt, backend håller bara referenserna och kontrollen innan ett bifall stängs läser dem ur verksamhetssystemet. Ett bifall räknas som försenat först tre arbetsdagar efter beslutet och inte direkt. Utbetalningstabellen och sektionsgodkännandena är borttagna
- Återkrav visas på beslutsfliken. Verksamhetssystemet har ingen egen post för återkrav, så ett beslut om bistånd mot återbetalning under de senaste 36 månaderna blir en varning med beslutstyp, datum, period och belopp. Inbetalningar och saldo syns inte, och handläggaren uppmanas kontrollera saldot i verksamhetssystemet. Beslutstyperna är inte upplagda än, så matchningen på namn behöver bekräftas mot dem. Tidsfönstret går att ställa in
- En misslyckad läsning i verksamhetssystemet stängde de varningar som byggde på den, och en stängd varning öppnas aldrig igen. Ett återkrav kunde alltså försvinna för gott. En misslyckad läsning ger nu i stället en egen varning, som stänger sig själv vid nästa lyckade läsning. Ett misslyckat uppslag av insatsen fick hela ärendet att ge fel. Det tolereras nu
- Inkomster från SSBTEK vars kategori har ett annat namn i verksamhetssystemet föll bort ur utkastet utan varning, till exempel barnbidrag, dagersättning och a-kassa. I ett testärende försvann därför både ett barnbidrag och en medsökandes dagersättning. Kategorierna slås nu upp även på verksamhetssystemets namn. En inkomst som ändå inte går att föra över ger varningen "Inkomst kunde inte föras över". Studiemedel, studiebidrag, elstöd och barntillägg hamnar där tills verksamheten sagt vilken typ de hör till
- Den manuella SSBTEK-läsningen är knuten till ett ärende. Den gäller ärendets sökande eller medsökande och loggas i åtkomstloggen som "Visade SSBTEK-underlag". Tidigare var den inte knuten till något ärende och kom därför inte med i loggen
- Dagkontrollen räknar midsommarafton som ersättningsdag, enligt verksamhetens besked 23 september. En riktig utbetalning för hela juni gällde 22 dagar
- Orsaken för medsökande följer med genom beslutet. Tidigare försvann den när beslutet fattades
- Inställningar per handläggare. Den första gäller om SSBTEK ska öppnas i en ny flik
- Aviseringarnas beskrivningar är på svenska i stället för engelska eller råa koder, till exempel "Utbetalningsbeslut: avslag"
web-app-drakel
- Första "Spara normberäkning" skapar beräkningen i verksamhetssystemet. Därefter läses och ändras den direkt där: inkomster, utgifter, levnadskostnader, norm och gemensamma kostnader. Verksamhetssystemet placerar personerna på normen och räknar summorna, också vid normbyte, och valen i listorna kommer ur dess kataloger. Före första sparningen visas utkastet från ansökan och SSBTEK som tidigare
- Dagar och normintervall går att ändra per person, vilket prioriterades på standupen. Verksamhetssystemet räknar personens belopp med dagarna i sitt eget fält, så Rakel räknar inte om beloppet själv. Ett intervall som redan är valt skrivs inte över. Vem som ingår i beräkningen avgörs i verksamhetssystemet, och personer kan inte tas bort från Rakel
- Knapparna "Spara normberäkning" och "Spara normberäkning som slutlig" finns alltid. Den slutliga sparningen kräver en bekräftelse och låser fliken
- Jobbstimulansen har flyttat till normberäkningens inkomstflik. Perioderna läses och läggs till direkt i verksamhetssystemet, och inkomsten anges som brutto i en egen kolumn, som i verksamhetssystemet. Dess procentsats räknar fram det som räknas som inkomst, så avdraget görs aldrig två gånger
- Föregående normberäkning läses ur verksamhetssystemet och väljs ur insatsens egen lista över beräkningar
- Förhandsgranskningen av normberäkningen visar verksamhetssystemets egen PDF, och läsningen loggas på ärendet
- Utbetalningar registreras direkt i verksamhetssystemet från utbetalningsfliken, och Rakel behåller ingen kopia. Samma kontroller som tidigare görs innan något skickas: saldo, betalsätt, månad, kontering, mottagare och hushåll. En likadan utbetalning som redan finns nekas, så att ingenting betalas två gånger. Fliken visar status på en rad, förifyller saldot och hela beloppet och listar de fem senaste utbetalningarna
- Beslutstypen förväljs som förslag utifrån backendens beslutsförslag, och gränssnittets egen utfallsregel är borttagen. Delvis bifall registreras med beslutstypen för bifall, eftersom typen för delvis bifall saknas i verksamhetssystemet. Orsaken förväljs från föregående beslut. Beslutsformuleringarna ligger i mallverktyget och redigeras på adminsidan. Vid bifall fylls "Bifall månad" i, eller varianten med barn, men bara en gång och bara i ett tomt beslutsmeddelande
- Knappen "Spara och skrivskydda beslut" sparar beslutet låst i verksamhetssystemet efter en bekräftelse. Därefter går beslutet inte att ändra från Rakel. Den vanliga sparningen finns kvar och skrivskyddar inte. Vilket fält verksamhetssystemet självt använder för att skrivskydda är ännu inte bekräftat
- Bockarna på flikarna följer verksamhetssystemet. Normberäkningen bockas när den är slutlig, beslutet när det är sparat och utbetalningen när månadens utbetalning är registrerad. "Markera som komplett" är borttaget, och besluta och utbetala kräver inte längre godkända sektioner
- Journal och dokument har två knappar, Spara och Spara och skrivskydda, som standupen beslutade. Posterna delas upp efter verksamhetssystemets typkod, och poster med andra typkoder visas inte. En knapp överst i journalen öppnar den migrerade journalen från det tidigare systemet som PDF. Tills den migrerade journalen finns visas samma testfil för alla ärenden
- "Hämta från SSBTEK" öppnar ärendets SSBTEK-sida i en ny flik, så att ärendet är kvar öppet. Sidan visar betalningar från Försäkringskassan, Pensionsmyndigheten och a-kassan i en tabell per månad, och varje rad kan fällas ut till sina delförmåner. Bara de fält som visas läses ut, så personnummer, namn och adresser i myndigheternas svar lämnar aldrig backend. Samma betalningar kan i stället visas i en panel längst ner på ärendet, och handläggaren väljer under Inställningar
- Inloggningen mot verksamhetssystemet fungerar utan webbläsare. Sidorna hittas igen under appens egen sökväg, där alla sidor tidigare gav 404
api-service-operaton
- Processen har inte längre stegen för att skapa normberäkningen eller för att låta roboten hämta journal, dokument och bevakningar, eftersom gränssnittet gör det direkt. De nya processversionerna är publicerade och alla pågående instanser migrerade
- Processen läser hushållets personnummer från det omdöpta gränssnittet, och beskrivningen av utbetalningskontrollen är uppdaterad
Backend- och processmotorarbetet ligger på grenen drakel i respektive repo. Robotens repo fick inga nya commits under dagen.
Öppna trådar
- Vilka värden som sätts när ansökan kommer in — ansökningsmånad, kontrollmånad, jämförelsemånad och ansökningsdatum — och hur mycket av det som redan är byggt bakom kulisserna.
- Aktualiseringen ska skapas direkt när ansökan kommer in, med rätt värden, och ansökan arkiveras på den direkt — inte i efterhand. En tilläggsansökan ska kunna arkiveras på samma aktualisering.
- Hur aktualiseringen knyts till rätt insats. Utgångspunkten är att det bara ska finnas en pågående insats för ekonomiskt bistånd, men lösningen behöver kunna läsa ut vilka insatser som finns — och det är oklart vad API:t stödjer.
- Gemensamma kostnader och hushållsstorlek: om handläggaren ändrar dem i Drakel och beräkningen skickas till verksamhetssystemet — följer värdena med till nästa månads beräkning, och kommer frågan om att spara som standard fram via API:t? Behöver testas. Alternativet är att roboten skriver det som sista steg när ärendet slutförs.
- Beslutsfliken behöver hämta föregående beslut och kunna föreslå orsak.
- RPA-spåret har två saker att bygga ifatt efter måndagens backend-ändringar: köposten för utbetalning bär numera bara ett betalnings-id — kontouppgifter läses via API:t i stället för att ligga i kölagret — och den nya uppgiften för att lägga in en betalningsmottagare i verksamhetssystemet finns ännu inte i roboten. En övergångsflagga håller den driftsatta roboten igång under tiden, och ingen återrapportering stänger ännu en registrerad utbetalning.
- Vilken period en inkomst hör till styrs av utbetalningsdatumet enligt verksamhetens svar. Regelverkets egen regel för aktivitetsstöd säger i stället "månaden som ersättningen avser" — motstridigheten är lyft till verksamheten.
- Om ett namngivet katalogvärde för aktualiseringen inte hittas i verksamhetssystemet faller lösningen i dag tillbaka på första valbara värdet och loggar avvikelsen. Om den i stället ska vägra skapa aktualiseringen är obesvarat, liksom regelverkets "Handläggare = Rakel", som krockar med att sätta klientens tidigare handläggare.
Levererat i kod
api-service-caremanagement
- Beslut och utbetalning fick egna endpoints: beslutsförslag, utbetalningsförslag och ett "Besluta och utbetala"-steg som slutför ärendet, plus en egen utbetalningsresurs där registrerade utbetalningar sparas
- Valbar betalningsmottagare: listan byggs av sökandens faktiska utbetalningar i Lifecare senaste tolv månaderna och fylls på med mottagare handläggaren lägger till manuellt. En manuell mottagare läggs in i Lifecare av roboten och smälter samman med sin Lifecare-motsvarighet vid nästa återansökan
- Personuppgifter ut ur RPA-kön: köposten bär bara ett utbetalnings- respektive mottagar-id — namn och kontonummer läses av roboten via API:t i stället för att ligga i Orchestrators kölager. En övergångsflagga låter den redan driftsatta roboten fortsätta fungera tills den släpps mot det nya kontraktet
- Vid slutförande varnas handläggaren om en beslutad mottagare ännu inte hunnit skapas i Lifecare — en varning, inte ett stopp, eftersom beslutet är handläggarens
- SSBTEK-läsfel hanteras enligt regelverket: när inkomsterna inte kan läsas körs inkomstreglerna inte alls, beräkningen lämnas orörd, handläggaren får besked om att ett nytt försök kommer, och varningen stängs av sig själv när en senare körning lyckas
- Ny varning när en inkomst som SSBTEK rapporterade föregående månad har försvunnit — skild från jämförelsen mot föregående normberäkning, eftersom de två skiljer sig just när handläggaren frångått rådata
- Aktualiseringens fyra värden (typ, orsak, från vem, organisation) sätts till dem verksamheten namngav i regelverket i stället för första valbara, och avvikelser loggas
- Beslutsförslaget använder Lifecares egen orsakskatalog i stället för platshållare och föreslår orsak även för medsökande. "Avvisning" är borttaget som utfall och delavslag heter nu "Delvis bifall" — enligt verksamhetens svar samma dag
- Läsbara varningar och beräkningsrader: namn i stället för person-id, roller och kostnadstyper med svenska etiketter ur en gemensam etikettkälla
- Rättningar i RPA-inhämtningen: Lifecare-tider läses i svensk tidszon (posterna låg två timmar fel), oförändrade leveranser skriver inte längre om "senast ändrad", och jobbstimulans skrivs bara om hela leveransen kunde läsas
api-service-operaton
- Inkomstreglerna uppdaterade efter verksamhetens svar samma dag: utbetalningsdatumet styr vilken period inkomsten hör till, fyra ersättningar jämförs inte längre mot föregående månad, och studiehjälp som egentligen är extratillägg känns igen på beloppet och räknas inte som inkomst
- Inkomster från Försäkringskassan, Pensionsmyndigheten och CSN läses rätt ur SSBTEK:s underlag, och en ersättning som försvunnit rapporteras inte längre som en förändring på −100 %
- Inkomstreglerna hoppas över när SSBTEK inte kunde läsas
- Misslyckade steg i processmotorn görs om med fördröjning i stället för att låsa hela instansen
web-app-drakel
- Utbetalningsfliken: formuläret kopplat till utbetalningsförslaget, registrering mot backend, lista över registrerade utbetalningar, kontering och valbar betalningsmottagare med egen lista. "Kvar att disponera" visas i stället för den tidigare Pengar-raden
- Beslutsfliken kopplad till beslutsförslaget, med förifyllda orsaker för både sökande och medsökande
- SSBTEK-läsfel visas som banner i ärendehuvudet och går inte att kvittera bort
- Normberäkningen jämförs med föregående månad och använder caremanagements etiketter i stället för egna
- Punkt 3, 4, 6, 10, 11 och 15 ur regelverket för återansökan byggda i gränssnittet, bland annat ihopslagna bilagor
- Bredare pdf-förhandsgranskning med öppna-i-ny-flik, och uppladdning av bilagor borttagen för handläggare
- Översikten ordnad om: "Alla ärenden" återinförd, "Sök ärenden" tillagd och ägarskapsfiltret rensat
web-app-business-center
- Justeringar i ansökningsformuläret, och kontaktuppgifter som visas som text men kan redigeras i en dialog
Backend- och processmotorarbetet ligger på grenen drakel i respektive repo.
Standup
Mötet inleddes med frågan vad som egentligen hann göras under måndagen — ingen hade riktigt överblicken. Genomgången av commit-historiken gav svaret: 71 commits över fyra repon, med utbetalningskedjan, beslutsförslagets orsaker, hanteringen av SSBTEK-läsfel och sex punkter ur regelverket. Att en dag kan vara så pass innehållsrik utan att kännas så är i sig argumentet för att sammanställa dagarna ur koden i efterhand, vilket loggen gör.
Fokus i dag
Dagen läggs på tre spår. Det ena är RPA-delarna som inte är på plats: roboten ska möta det kontrakt backend fick i går — utbetalningen läses via API:t i stället för ur köposten, den nya uppgiften för att lägga in en betalningsmottagare i verksamhetssystemet ska byggas, och en återrapportering som stänger en registrerad utbetalning saknas helt.
Det andra är miljön: backend-tjänsterna sätts upp lokalt på kommunens nätverk, så att de kan läsa från den lokala Lifecare-instansen i stället för utifrån. Det är förutsättningen för veckans end-to-end-spår — når tjänsterna inte verksamhetssystemet inifrån nätverket går flödet inte att köra mot riktig data.
Till det hör testdata: en testperson som finns i SSBTEK ska också finnas i Lifecare och i metakatalogen. Utan en person som går att följa genom alla tre går flödet inte att köra från ansökan till beslut, och det är samma förutsättning som end-to-end-spåret vilar på.
Levererat i kod
api-service-caremanagement
- Resten av verksamhetens svar från 21 sep infördes: internet är borta ur kostnadstyperna, beslutstabellen och katalogen — kostnaden ingår i riksnormen från 2027 — föräldrapenningens periodkontroller är tagna ur regelverket, och betalsättens värdemängd är inlagd
- Två fel som gjorde "Besluta och utbetala" obrukbar hittades i drift: statuskolumnen var för smal för det värde en beslutad utbetalning får, och utbetalningsraderna sparades inte till databasen förrän efter att beslutet redan gått vidare till processmotorn och robotkön. Ett ärende kunde därmed bli beviljat på ett beslut som inte fanns. Båda rättade, med ett test som håller statusvärdena inom kolumnens bredd
- Utbetalningen bär nu mottagarradens id hela vägen, så roboten får verksamhetssystemets egen mottagar-id i stället för att matcha på namn och kontonummer — en matchning som misslyckas tyst
- Roboten kan rapportera tillbaka vad verksamhetssystemet gjorde med utbetalningen, med samma tre fält som för betalningsmottagare, så en beslutad utbetalning inte blir kvar i väntläge för alltid
- Nytt endpoint som visar vad SSBTEK faktiskt svarade, per myndighet och över regelverkets tre perioder, vid sidan av de klassificerade inkomsterna. Personnummer passerar inte API-gränsen
- Hela läsningen och skrivningen mot verksamhetssystemet kan nu gå via integratorn i stället för direkt mot FamilyCare — förutsättningen för att tjänsterna ska nå verksamhetssystemet inifrån kommunens nätverk. Vilken väg som används styrs av en egen inställning, och den direkta vägen är fortfarande standard
- Ansökningsdatum sätts från inskickningsdatumet enligt regelverkets revision 22 sep; tidigare användes månadens första dag, vilket kunde ligga upp till en månad fel
- Ny varning när en inkomst i jämförelseperioden förs över sent — den enda regeln i regelverket som både ändrar normberäkningen och varnar om det
- Loggningsavsnittet i regelverket byggt: uppföljning per handläggare över alla ärenden, och sökträffar loggas rad för rad
- Ett ärende hamnar hos klientens tidigare handläggare bara om insatsen fortfarande är öppen — verksamheten fick välja mellan de två läsningarna och valde regelverkets ordalydelse
- Aktualiseringen länkar bara den insats och utredning som aktualiseringstypen accepterar; tidigare togs den första som erbjöds, vilket verksamhetssystemet svarade 400 på så att aktualiseringen aldrig skapades
- Personnummer sätts inte längre som processvariabler i processmotorn — beredningen hämtar identiteterna per körning i stället, så varje utlämning hamnar i ärendets logg
- Normberäkningen räknas mot den norm ansökan begärde och inom de dagar perioden tillåter; tidigare föll varje återansökan på ett tomt 400 vid commit av beräkningen
- FAMILJ-raden får belopp per hushållsmedlem, och "Hanterad" blir en egen status på notiser vid sidan av läst
web-app-drakel
- Utbetalningsformuläret använder verksamhetssystemets riktiga betalsätt i stället för gissningen, och skickar med mottagarradens id så roboten slipper matcha på namn och konto
- Utbetalningens statusar heter något i gränssnittet: "Väntar på registrering" och "Registrerad i Lifecare" — det sista säger att utbetalningen finns i verksamhetssystemet, inte att den är utbetald
- Statusfiltret i översikten fungerar igen och har fått sällskap av ett filter på ärendetyp; vyn landar på Pågående, och sidomenyns grupp heter Mina ärenden eftersom den alltid visar handläggarens egna
- Ny administrationssektion: mallar och frastexter för journalanteckningar och dokument på en egen sida, och logguppföljning på en annan — vad en handläggare läst och ändrat över alla ärenden. De två uppdragen styrs av var sin AD-grupp, eftersom att underhålla mallar och att följa upp vem som läst vilket ärende inte är samma förtroende
- Beslutssteget får ett fjärde utskicksval vid sidan av Mina sidor, digital brevlåda och brev: ett meddelande handläggaren själv skriver, omarkerat från början
- Internet är borta som kostnadstyp, men etiketten behålls för ansökningar som redan innehåller den
- Normberäkningens FAMILJ-tabell följer verksamhetssystemets egen beräkningsvy kolumn för kolumn — personnummer och belopp in, roll ut — och en sektion som markerats komplett tonas ner i stället för att bara vara inaktiverad
- När ett system bakom API:t nekar behålls skälet hela vägen fram, så handläggaren ser vilket underlag det inte gick att arbeta med
api-service-operaton
- Studiehjälpens säsongsregel byggd enligt verksamhetens svar 22 sep: en separat SSBTEK-läsning bakåt till juni används bara för den frågan, och vidgar inte den ordinarie hämtningen
- Processen gick ner under dagen — SSBTEK-underlaget växte förbi motorns teckengräns och varje hämtning föll med ett generiskt fel i persistenslagret som inte sa vad som var fel. Underlaget hålls nu utanför motorns historiktabeller
- En egen serialiserare säger uttryckligen ifrån när en processvariabel är för stor, i stället för att misslyckas tyst efter att alla omförsök redan brunnit
- Beredningens fem steg slås ihop till ett, så inkomstunderlaget aldrig behöver ligga som processvariabel — både en storleksfråga och en integritetsfråga, eftersom motorns historik sparas i 180 dagar
RPA-Drakel
- Robotens första skrivande operation är på plats: den registrerar utbetalningen i verksamhetssystemet. Köposten bär bara ett betalnings-id, uppgifterna hämtas via API:t och mottagaren pekas ut direkt när verksamhetssystemets mottagar-id är känt — annars matchas kontonumret, och två mottagare med samma konto ger fel i stället för en gissning
- Köpostens fält läses på ett ställe i stället för i varje operation, vilket är det som gör den nya operationen testbar
- Ett testfall som skapar en riktig utbetalning i verksamhetssystemet och loggar betalnings-id:t — det är vad som behövs för att makulera den efteråt
web-app-business-center
- Internet togs bort ur ansökningsformuläret. Kostnadsrutorna renderas från en egen lista i frontend och inte från API:ts katalog, så rutan överlevde borttagningen i backend och varje ansökan som kryssade i den nekades vid inskick tills den togs bort även här
Backend- och processmotorarbetet ligger på grenen drakel i respektive repo, robotens utbetalningsoperation på en egen gren.
Öppna trådar
Verksamhetens svar på frågelistan har kommit, och tre av gårdagens trådar stängs med det: Rakel ska stå som den som registrerat aktualiseringen medan ärendet fördelas till ärendets registrerade handläggare, utbetalningsdatumet styr vilken period en inkomst hör till, och jämförelsen mellan månader ska vara exakt i stället för en tolvprocentsgräns. Det som blev kvar — eller nytt — ligger här.
- Frågan om vilken helgdagskalender som gäller kom tillbaka till teamet: verksamheten har ingen källa att peka ut och ber oss föreslå en. Den behövs på två ställen — dagkontrollen jämför uttagna dagar mot icke-röda dagar i kontrollmånaden, och utbetalningsdatumet den 27:e ska flyttas till vardagen innan även vid röda dagar.
- Vilka betalsätt verksamhetssystemet använder, vilka fält respektive betalsätt kräver och vad bokföringsdatum styr är obesvarat. Riktningen är däremot klar: handläggaren ska välja bland klientens befintliga betalningsmottagare med förifyllda uppgifter. Utbetalningsformuläret vilar till dess på en gissning.
- Rålistan vänds: inget som står på den ska varnas, och allt som saknas på den ska varnas. Beslutet är fattat, men innebär att sex publicerade varningsrader ska bort och att varningsvolymen blir känd först när vi kört mot riktig data. Samtidigt ska handläggaren se alla avvikelser samtidigt i stället för en prioriterad varning — beslutstabellerna ger i dag högst ett utfall per utvärdering.
- Två inkomstregler ligger kvar hos verksamheten: vilket inkomstslag barntillägg hör till, som är en ny inkomst från oktober, och hur studiehjälpens uppehållsmånader ska hanteras.
- Två förfrågningar utanför kommunen är skrivna men inte skickade. Försäkringskassan och arbetslöshetskassornas samorganisation behöver ge kodlistan för statussvaren och en testidentitet med ifyllt underlag, samt förklara varför kommunens testkonto är behörighetsspärrat för arton förmånsgrupper — så länge ser "vi får inte se barnbidrag" likadant ut som "inget barnbidrag finns". Till verksamhetssystemets leverantör gäller frågan om API-nyckel i header, om kodlistorna är stabila och om det finns API för betalningsmottagare och kontering.
- Tre mindre trådar: dagkontrollerna räknas inte som färdiga förrän vi fått två till tre verksamhetsgodkända räkneexempel med exakta förväntade utfall; frågan om vilka statusvärden som betyder öppet ärende kom tillbaka som en motfråga och besvarades med att det beror på sammanhanget, insats eller utredning, vilket inte räcker för att låta flaggan styra något; och informationstexten för tilläggsansökan saknas fortfarande, så bara återansökan går att testa.
Standup
Standupen började med en genomgång av handläggargränssnittet. Översikten visar handläggarens pågående och avslutade ärenden, och den nya sökvyn kräver ett sökord innan den filtrerar på status, ärendetyp och handläggare. Behovet kommer ur vardagen: vid frånvaro ska ett ärende gå att lämna över, ett meddelande besvaras eller en journalanteckning skrivas av någon annan än den ordinarie handläggaren.
Administrationen visades i två delar — mallar och frastexter som går att lägga till, ändra och ta bort, och logguppföljningen där man ser vad en användare har gjort. De styrs av var sin AD-grupp, och logguppföljningen är tänkt som en chefsbehörighet, även om testmiljön just nu ger alla samma rättigheter. En idé som kom upp under demon: hämta mallarna direkt ur verksamhetssystemet, så att de bara behöver underhållas på ett ställe. Bilagevisningen är samtidigt uppstädad, med en knapp som öppnar bilagan i egen flik så att den går att läsa bredvid ansökan.
Utbetalningen går i teorin nu hela vägen från gränssnittet till roboten, inklusive att lägga till en betalningsmottagare, men kedjan har inte körts skarpt. Det som däremot sker på riktigt är aktualiseringen: skickas en ansökan in i dag läggs en aktualisering upp i verksamhetssystemet, den går att välja i pluklistan, driva vidare i flödet, skapa en beräkning på och arkivera ansökan mot.
Mötet stannade en stund vid vad end-to-end egentligen ska omfatta. Utgångspunkten är hela vägen: ansökan på Mina sidor, beredning, handläggarens beslut och besked tillbaka till klienten om att beslut fattats och utbetalning skett. Kopplingen mot roboten är ännu inte helt ihopknuten, så en körning hela vägen ligger sannolikt några dagar bort — och för att kunna logga in som testperson på Mina sidor behöver det också skapas ett party för personerna.
Att visa klientens aktiva beslut ur verksamhetssystemet på Mina sidor konstaterades vara en strategisk fråga för hela kommunen snarare än teamets önskemål: beslutsfliken gäller alla verksamheter och utreds vidare under hösten. Teamets eget önskemål är att beslutet skickas i meddelandefunktionen så att klienten kan svara, och att den vägen fungerar räcker som test av flödet.
Den största nyheten från gårdagen är att RPA-delen kan krympa. Verksamhetssystemets interna, opublicerade API går att anropa utan roboten, med ett servicekonto som loggar in på samma sätt som roboten gör. Det tar bort väntan på robotens dygnskörning för de delar där svaret behövs direkt. Robotens läsdel är färdig och lämnas orörd — den är det sista som ersätts, och kopieras inte i onödan under tiden.
Fokus i dag
Dagen läggs på att ersätta fler robotsteg med direktanrop mot det interna API:t, med start i bifogandet av beslut, och på slutknuten i utbetalningsprocessen. Parallellt tittar verksamhet och team tillsammans på hur SSBTEK-svaret ska visas och hur sökningen ska fungera — det tas på ett möte senare i dag.
Levererat i kod
Koden följer dagens fokus. Handläggargränssnittet läser och skriver nu direkt i verksamhetssystemet för journal, dokument, bevakningar, betalningsmottagare, utbetalningar och beslut, och roboten kan stängas av åtgärd för åtgärd när ett steg tas över. Samtidigt rättades en rad fel som först syntes när flödet kördes mot det riktiga verksamhetssystemet.
api-service-caremanagement
- Steget "Aktualisera & arkivera ansökan" hade aldrig arkiverat något — det skapade aktualiseringen och stannade där. Nu laddas både själva ansökan och sammanställningen av klientens bilagor upp på aktualiseringen, med filnamn som bär ärendenumret, och utfallet — arkiverat, inget att arkivera eller misslyckat — syns på ärendet i stället för i en logg. Ett misslyckat arkiv får aldrig göra att aktualiseringen skapas en gång till
- Tre fel på vägen dit hittades mot det riktiga verksamhetssystemet: sammanställningen söktes under fel dokumenttyp och hittades aldrig, dokumenttyperna skickades som påhittade ord i stället för katalogens nummer, och en uppladdning tog över 40 sekunder mot en tidsgräns på 30. Tidsgränsen är nu 90 sekunder
- Verksamhetssystemets egen förklaring når nu fram till ärendet och processens incident, i stället för "Unknown error" — till exempel "Saknar norm för angiven hushållsstorlek". Meningen fanns hela tiden men tappades ett led före den som skulle läsa den, och varje fel har kostat en letning i loggarna
- Normberäkningen kopplas bara till ärendets egen insats för ekonomiskt bistånd. Tidigare togs personens första öppna insats och utredning inom hela socialtjänsten, vilket verksamhetssystemet vägrar, så beräkningen för ett testärende gick inte att skapa
- En inkomstrad som handläggaren lagt till saknade verksamhetssystemets id för inkomstslaget och nekades. Id:t slås nu upp på namnet, och en inkomst som inte går att slå upp nekas med namn i stället för att tyst falla bort — en utelämnad inkomst ändrar det beviljade beloppet
- Det förra beslutet som beslutsförslaget utgår från väljs bara bland beslut om ekonomiskt bistånd. Tidigare kunde ett beslut från en annan del av individ- och familjeomsorgen stå som förra månadens beslut, utan orsak och period, och varningen för förskott på förmån kunde aldrig slå till
- Dagkontrollen för dagersättning byggd enligt verksamhetens beslut: inget ekonomiskt beslut från Arbetsförmedlingen eller alla dagar i jobb- och utvecklingsgarantin förbrukade ger ingen kontroll, ingen utbetalning i kontrollmånaden ger en varning, och annars jämförs uttagna dagar med icke-röda dagar. Lördagar räknas som röda eftersom ersättningen betalas för högst fem dagar per vecka, och julafton och nyårsafton räknas som ersättningsdagar enligt verksamhetens svar. Midsommarafton är fortfarande öppen och tolereras på båda sätten
- Förskott på förmån känns igen på beslutstypen och inte på fritextorsaken, enligt verksamhetens svar
- En betalningsmottagare som handläggaren väljer direkt ur verksamhetssystemet följer nu med hela vägen genom beslutet, med adress, räkningsnummer och lokalbetalningsnummer. Den tidigare förslagstjänsten för utbetalning togs bort när gränssnittet började läsa förslaget ur verksamhetssystemet
- Kontrollen innan ett bifall stängs räknade vilken utbetalning som helst till personen för månaden — ett annat ärendes eller en äldre insats — och kunde stänga ärendet trots att beslutets utbetalning saknades. Nu kontrolleras exakt ärendets egna utbetalningar mot deras id i verksamhetssystemet, och ett ärende som inte går vidare säger vilket steg som saknas
- Utbetalningar som väntat mer än tre arbetsdagar efter beslutet markeras som försenade, och ett bifall helt utan utbetalningar är försenat direkt. Markeringen används bara för att avisera handläggaren — inget stängs på den
- Om beslutsmeddelandet inte når processen köas det och skickas om med ökande intervall i upp till tre dygn innan det loggas som fel. Tidigare blev ärendet stående med ett beslut medan processen väntade, tills någon skickade om för hand
- Stöd för att gränssnittet arbetar direkt i verksamhetssystemet: ärendet bär insatsens id, gränssnittets egna läsningar och skrivningar loggas i ärendets åtkomstlogg enligt regelverket — utan råa sökvägar, eftersom de innehåller personnummer — och ett beslut rapporterar om det kom in i verksamhetssystemet. Ärendet sparar bara nyckeln till beslutet, inga beslutsdata
- Roboten kan stängas av en åtgärd i taget, så att ett steg kan tas över av direktanrop utan att samma skrivning görs två gånger
- Handläggaren kan lägga till och ta bort medhandläggare på ett ärende direkt i Rakel, och aviseringarna på ärendet syns då även för medhandläggarna
web-app-drakel
- "Besluta och utbetala" skickade bara beslutet och stängde ärendet — orsak, period, belopp och utbetalningar sparades aldrig, och processen fastnade i handläggarens beslutssteg. Knappen går nu genom backendens slutförande, kräver att alla tre sektioner är godkända och listar det som inte gick igenom efter att ärendet beslutats
- Beslutsfliken sparar beslutet direkt i verksamhetssystemet, med beslutstyper och orsaker hämtade därifrån, och förhandsgranskningen är verksamhetssystemets egen utskrift — samma som skickas till den sökande. Frastexterna fylls i med namn, belopp och period ur beslutet
- Vid besluta och utbetala registreras det beslut handläggaren fattat i verksamhetssystemet innan utbetalningarna, eftersom saldot de dras från kommer ur beslutet. Beslutsfattare är handläggarens eget konto, med ett särskilt testkonto som reserv i testmiljön. Delvis bifall, hushåll med medsökande och okänd orsak eller beslutsfattare stoppas med en förklaring, och svarar verksamhetssystemet inte görs inget nytt försök — det skulle ge ett andra beslut
- Journalanteckningar och dokument läses, redigeras och skapas direkt på ärendets insats i verksamhetssystemet, på samma sätt som dess egen editor, och kan sparas skrivskyddade. Verksamhetssystemets valideringsmeddelanden visas, så att handläggaren kan rätta i stället för att få ett generiskt fel
- Journal- och dokumentflikarna visar varje posts text direkt i listan och har en sökruta per flik som filtrerar på rubrik, typ, akt, handläggare och text — ett första svar på morgonens tråd om att sök väger tyngre än en lång lista
- Betalningsmottagare och betalsätt läses ur verksamhetssystemet och nya mottagare skapas där direkt. En identisk befintlig mottagare återanvänds, eftersom verksamhetssystemet inte skyddar mot dubbletter
- Hela utbetalningsfliken läses ur verksamhetssystemet — status, saldo, registrerade utbetalningar och förslag. Utbetalningarna registreras en i taget efter beslutet och bara när saldot täcker beloppet; annars väntar de och kan registreras från fliken
- Bevakningar läses, skapas, ändras och tas bort direkt på insatsen i verksamhetssystemet
- Varje läsning och skrivning gränssnittet gör i verksamhetssystemet rapporteras till ärendets åtkomstlogg, och en läsning som inte kan loggas lämnas inte ut
api-service-operaton
- Processen matar dagkontrollen med Arbetsförmedlingens ekonomiska beslutsperioder och Försäkringskassans förbrukade dagar i jobb- och utvecklingsgarantin, vilket slår på kontrollen. En myndighet som saknas eller svarat med fel lämnar kontrollen avstängd i stället för att läsas som att den svarat med ingenting. Fälten är hämtade ur myndigheternas scheman och har ännu inte setts i ett riktigt SSBTEK-svar
- Innan ett bifall stängs kontrolleras ärendets egna utbetalningar, även för instanser som redan väntar, och skälet till att en utbetalning inte räknas som genomförd syns i processmotorns översikt
- En försenad utbetalning aviserar ärendets handläggare en gång. Handläggaren läses när steget körs, så en omfördelning under väntan respekteras, och ett ärende utan handläggare blir en incident direkt i stället för ett tyst omförsök
- Testtäckningen återställd över kvalitetsgränsen, som fått bygget att falla på grenen
RPA-Drakel
- Biblioteket mot verksamhetssystemets interna API har delats upp i åtta delar, och robotens anrop — tio aktiviteter på tretton ställen — har flyttats med. Roboten går att köra igen först när biblioteket publicerats på nytt
Backend- och processmotorarbetet ligger på grenen drakel i respektive repo, robotens anpassning på grenen för utbetalningsoperationen.
Öppna trådar
- Hur dokument och journal ska presenteras i dokumentationsfliken är oklart. Journalen kan sträcka sig flera år tillbaka och blir tyngre för varje månad, och ingen tidsgräns är beslutad för hur långt bak lösningen ska läsa. Verksamheten söker i dag i journalanteckningarna i verksamhetssystemet när en gammal bedömning behöver hittas — hyran, ett busskort, något som ska dubbelkollas — så en sökfunktion väger tyngre än en lång lista. Sidindelning finns som alternativ på vår sida.
- Vid nyansökan behöver det bestämmas hur filerna ska presenteras när handläggaren väljer bland dem. De kan vara många, och lösningen kan inte peka ut vilken som är den rätta — men får heller inte lämna över hela bedömningen utan stöd.
- Testpersonerna behöver ett party för att gå att logga in som på Mina sidor. Det är påbörjat men inte bekräftat klart, och utan det går inte sista steget i flödet att se från klientens sida.
- En ny frågeomgång till verksamheten är besvarad, och den tar bort det som blockerade dagkontrollen: icke-röda dagar är vardagar måndag–fredag minus de allmänna helgdagar som infaller på vardag, medan julafton och nyårsafton räknas med eftersom ersättning generellt betalas för dem. Samma kalender gäller utbetalningsdatumet. Förskott på förmån registreras på samma insats som övriga beslut om ekonomiskt bistånd och känns igen på beslutstypen, inte på orsaken.
- Två nya beroenden mot hur verksamhetssystemet är konfigurerat. Beslutstypen för delvis bifall finns inte upplagd ännu, så bara bifall och avslag går att registrera. Och handläggarna saknas i listan över beslutsfattare — verksamheten svarar att Rakels eget konto får stå som beslutsfattare så länge, vilket måste ändras innan lösningen används skarpt: det är handläggaren som fattar beslutet och som ska stå för det.
- Ett testhushåll med medsökande finns nu i testmiljön, så beslut och kontroller för hushåll med två sökande går att verifiera.
- Midsommarafton finns inte med i verksamhetens svar om icke-röda dagar. Julafton och nyårsafton räknas som ersättningsdagar, men för midsommarafton godtar dagkontrollen båda läsningarna tills frågan är besvarad.
- Dagkontrollen är nu påslagen i processen, men fälten den läser — Arbetsförmedlingens ekonomiska beslut och Försäkringskassans förbrukade dagar i jobb- och utvecklingsgarantin — är hämtade ur myndigheternas scheman och har ännu inte setts i ett riktigt SSBTEK-svar. Hur kontrollen beter sig visar sig först när flödet körs hela vägen mot riktig data.
Standup
Standupen ägnades mest åt en fråga som gårdagens ombyggnad väckte: när ska det handläggaren gör i Rakel registreras i verksamhetssystemet? Sedan i går skrivs journalanteckningar, dokument, bevakningar, utbetalningar och beslut direkt dit, och svaret blev olika beroende på vad det gäller.
Journalanteckningar och dokument sparas i dag med en knapp som samtidigt skrivskyddar, och det som skrivskyddats går inte att ändra. Det behövs två knappar i stället — en framträdande som sparar och skrivskyddar och en som bara sparar — i både journal- och dokumentfliken.
Normberäkningen ska synkas ett till ett med verksamhetssystemet hela tiden och ligga där som preliminär tills handläggaren sparar den som slutlig. Det fanns en invändning: handläggningen sker i Rakel, och ingen behöver titta på normberäkningen i verksamhetssystemet under tiden. Speglingen vägde ändå tyngre. Verksamhetssystemets egen uträkning av jobbstimulansen kan då användas direkt i stället för att räknas om i Rakel, verksamhetssystemet blir facit, och ligger Rakel nere finns arbetet kvar där, så att akuta ärenden kan handläggas ändå. Knappen som sparar beräkningen som slutlig ska vara svår att trycka på av misstag, med en bekräftelse, eftersom beräkningen är låst efteråt.
För beslut och utbetalning blev svaret det motsatta: beslut som inte är skrivskyddade ska inte ligga i verksamhetssystemet. Handläggaren fyller i beslut och utbetalning och registrerar dem i ett enda steg med en tydlig knapp som sparar som slutligt — i praktiken att skicka beslutet — och därefter är allt låst. Då behöver ingenting mellanlagras, med nackdelen att det som fyllts i går förlorat om sidan laddas om innan dess. Blir något fel får en superanvändare i verksamhetssystemet låsa upp beslutet, och det speglas då tillbaka så att handläggningen kan fortsätta i Rakel. Att beslutet sparas och skrivskyddas i verksamhetssystemet gör också att dess automatiska journalanteckning skapas.
Med gårdagens ombyggnad verkar direktanropen ha kommit ikapp allt roboten tidigare gjorde, så flödet går nu utan robot. Bevakningar och en del av mallarna hämtas direkt ur verksamhetssystemet, och journalanteckningar och dokument hämtas på personnumret och inte per insats — allt som ligger på personen.
Journal- och dokumentflikarna har fått sök och ett fritextfilter, och nästa steg är hur PDF:er från verksamhetssystemet ska visas. Den migrerade journalen blir ett dokument som får ett fast namn vid migreringen, så att Rakel kan känna igen den och visa den överst eller bakom en egen knapp. Den ska alltid finnas med, inte bara under de första månaderna. Tre andra dokument migreras också, men de är inte handläggning och behöver inte visas här. Migreringen görs av roboten, så för att testa räcker det att lägga in valfri PDF under det namn som bestäms.
Det som bedömdes som mest avgörande var normberäkningens dagar. Rakel behöver läsa ut kolumnen för dagar ur verksamhetssystemet och ha ett regelverk för vad som händer med beloppet när dagarna ändras: utgångspunkten är månadsbeloppet, och gäller beräkningen bara 15 dagar blir det ungefär hälften. Utan det blir beloppen i besluten fel, och då går det varken att handlägga i Rakel eller att testa att summorna blir rätt. Den prioriteras — helst så att verksamheten hinner testa medan de är på plats den här veckan, även om något annat då kan behöva skjutas till nästa vecka.
Fokus i dag
Normberäkningen först: synkningen mot verksamhetssystemet, knappen som sparar som slutlig och normberäkningens dagar. Därefter att beslut och utbetalning registreras i ett enda steg. I morgon knyts veckan ihop med en kort demo, där även robotdelen är med.
Öppna trådar
- Journalanteckningar och dokument hämtas på personnumret, och då kan poster från andra verksamheter följa med — poster som handläggarna inom ekonomiskt bistånd inte ska ha behörighet till. Hur urvalet ska avgränsas är inte bestämt.
- Hur knappen som sparar som slutligt ska se ut, så att den inte går att trycka på av misstag, stäms av med verksamheten. Förebilden är hur registrering av beslut fungerar i verksamhetssystemet: först spara, sedan en fråga om beslutet ska sparas som slutligt.
- Regelverket för normberäkningens dagar behöver preciseras — hur beloppet räknas om när dagarna ändras och om en månad ska räknas som 30 eller 31 dagar.
- Den migrerade journalens namn behöver bestämmas innan den går att känna igen och testa.
Standup
Standupen sammanfattade veckan. Alla punkter i funktionslistan är nu gul- eller grönmarkerade, det vill säga byggda eller levererade. Helomvändningen mitt i veckan gjorde det möjligt: i stället för att låta en robot arbeta i verksamhetssystemet läser och skriver Rakel nu direkt mot dess interna API, och all RPA är borttagen ur lösningen.
Nu återstår att visa att delarna fungerar tillsammans hela vägen, från ansökan till utbetalning.
Fokus i dag
End-to-end-tester. Målet är att både en nyansökan och en tilläggsansökan ska gå igenom hela flödet. En ny testperson läggs in på Mina sidor och skickar in en nyansökan, och den ansökan testas sedan genom flera flöden. I eftermiddag hålls en demo av veckans arbete.
Levererat i kod
Dagens stora steg är att kopplingen mot Lifecare flyttade från gränssnittet till backend. Allt handläggaren gör i Lifecare går nu genom CareManagement, som kontrollerar varje anrop, kopplar det som skapas till ärendet och loggar det. CareManagement når Lifecare via Lifecare-integratorn inne i kommunens nät, och det interna API:et används med ett integrationskonto. Gränssnittets egen Lifecare-koppling är borttagen. Parallellt rättades de fel som verksamheten hittade när den testade under dagen, och SSBTEK visar nu hela hushållet.
api-service-caremanagement
- Kopplingen mot Lifecares interna API har flyttat hit från gränssnittet: normberäkning, beslut med utskrift, utbetalningar och betalningsmottagare, jobbstimulans, bevakningar, journal, dokument och flikarnas status. Varje läsning och skrivning loggas i ärendets åtkomstlogg, och det som skapas kopplas till ärendet direkt. Kopplingen kan gå via Lifecare-integratorn, eftersom backend inte själv når Lifecare utanför kommunens nät
- Slutförandet läser själv beslutet i Lifecare och kvitterar det i samma steg, så att gränssnittet inte längre behöver skicka beslutet eller rapportera tillbaka
- Förslaget till normberäkning skapas i Lifecare redan vid första beredningen. Tidigare väntade det på ett komplett SSBTEK-underlag, och eftersom SSBTEK aldrig rapporterar Swish skapades det sällan för en återansökan. Inkomster som sökanden själv angett, till exempel Swish, lön och underhållsbidrag, följer nu med i förslaget
- Normberäkningen i Lifecare hålls i takt med SSBTEK. Ändras SSBTEK efter att beräkningen sparats blir det en varning med SSBTEK:s belopp före och efter. En ändring handläggaren själv gjort i beräkningen ger ingen varning. Varningar som den sparade beräkningen redan löser stängs
- Inkomständringar jämförs med föregående normberäkning i Lifecare, enligt verksamhetens beslut om vad "föregående månad" betyder, och inte med SSBTEK:s föregående månad. En förmån som är ny för månaden redovisas som ny inkomst
- Fyra fel som verksamheten hittade i dag är rättade: gemensamma kostnader blev 0, familjens belopp räknades på dagar trots hel månad, avslag föreslogs trots normunderskott och föregående beslut hittades inte. Beslutsförslaget utgår nu från den sparade beräkningen i Lifecare, även för vilka utgifter som inte godkänts
- SSBTEK-inkomster för barn i hushållet går igenom samma regler och varningar som de vuxnas, enligt verksamhetens beslut i dag. De förs över på sökandens rad med barnets namn i anteckningen
- Inkomster som bara sökanden kan uppge förväntas inte längre från SSBTEK. Tidigare blev en återansökan stående som ofullständig med en varning som inget SSBTEK-svar kunde stänga
- En nyansökan aktualiseras med nyansökans typ och kopplas inte längre till personens tidigare, avslutade utredning. Tidigare kunde ingen nyansökan aktualiseras, eller så nekades bilagorna
- Dubbla utgiftsvarningar är borttagna, och anteckningar som skickas till Lifecare hålls inom dess gräns på 80 tecken
- Lifecare-dokument kan hämtas som PDF, som förberedelse för att bifoga dem till beslutet
web-app-drakel
- Gränssnittets egen Lifecare-koppling är borttagen, med inloggning, session och översättningar. Normberäkning, beslut, utbetalning, bevakningar, journal, dokument och flikstatus går via CareManagement. CareManagement, mallverktyget och katalogtjänsten nås via kommunens API-gateway. Ändringen är sammanslagen till huvudgrenen
- "Besluta och utbetala" heter nu "Skicka beräkning och beslut". Dialogen föreslår ett meddelande i rich text som går att redigera. Beslut och normberäkning från Lifecare är bifogade från början, och egna PDF-filer går att lägga till. Beslutet skickas som meddelande i ärendet eller som brev. Mina sidor sparas som val men skickas inte än
- SSBTEK-sidan visar medsökandes och barnens betalningar tillsammans med sökandes, med personnummer och utseendet från skisserna. Inkomster som saknas i normberäkningen kan bockas i och föras över med SSBTEK:s belopp, och perioden går att välja upp till två år bakåt
- En registrerad utbetalning som inte kunde kopplas till ärendet ger en varning, och den får inte registreras igen
- Personnumret visas i ärendekortet, bilagor i meddelanden visas i samma PDF-vy som sammanställningen och "Nytt ärende" är dolt tills vidare
- Adminsidorna går att scrolla, logguppföljningen stoppas inte längre av annonsblockerare och tecknen som ersätts i beslutsformuleringar visas i adminvyn
api-service-lifecare-integrator
- En ny väg vidare till Lifecares interna API för CareManagement. Integratorn loggar in med integrationskontot, håller sessionen och skickar tillbaka Lifecares svar oförändrat. Anropen hålls utanför loggningen av innehåll, eftersom de bär personnummer och handläggarens text
- Integrationskontot når inte inloggningstjänsten från integratorns miljö. Tills vidare används en session som skapats någon annanstans och hålls vid liv. När Lifecare släpper den behöver en ny läggas in
api-service-operaton
- Beredningen läser SSBTEK även för barnen i hushållet
web-app-business-center
- Ansöknings-PDF:en följer e-ansökan och har fått kommunens brevmall med logotyp
Backend-, integrator- och processmotorarbetet ligger på grenen drakel i respektive repo. Robotens repo fick inga nya commits under dagen.
Vad sprinten levererade
Tvåveckors-sprinten v.25–26 (15–26 juni 2026) är genomförd och avslutades med en slutdemo den 26 juni. Den följde på innovationsdagarna 5–7 maj och var det andra projektet som testade kommunens nya arbetssätt — den här gången i ett verksamhetsnära, myndighetsutövande område.
Hypotesen som testades: Att ett tvärfunktionellt team utan mellanlager — parat med AI som aktiv medarbetare och med stark verksamhetsförankring genom innovationsdagarna — på två veckor kan leverera en första, sammanhängande version av beslutsstöd och automatiserad ärendeberedning för ekonomiskt bistånd. Givet att verksamhetssystemet ännu inte är konfigurerat byggdes lösningen mot API-spec med mockad data (se Insikt 01); verifiering mot riktig data sker i Fas 3.
9 arbetsdagar · 4 repon · 342 commits
Under nio arbetsdagar (två veckor minus midsommarafton) gjordes 342 commits över fyra kodrepon — web-app-drakel (144), api-service-caremanagement (109), web-app-business-center (70) och api-service-operaton (19). Av de 70 funktioner listan omfattade vid sprintens slut var 28 levererade och verifierbara, 30 byggda mot spec (väntade på riktig data) och 12 ej påbörjade eller blockerade. Listan har sedan dess vuxit till 94 poster i takt med att regelverket preciserats, och fördelningen är i dag 44 levererade, 47 byggda mot spec och 3 som utgått, och ingen punkt är kvar — se Funktionslista.
Vad uppföljningssprinten levererade
Enveckssprinten v.39 (21–25 september 2026) är genomförd och avslutades med en slutdemo och ett retrospektiv den 25 september. Den första sprinten byggde lösningen mot API-spec med mockad data. Den andra skulle göra den verifierad och stänga de frågor och funktioner som blev kvar.
Hypotesen som prövades: Att en fokuserad vecka räcker för att ta lösningen från byggd mot spec till verifierad end-to-end, i den utsträckning verksamhetssystemet är konfigurerat. Utfallet: ett ärende har gått hela vägen i testmiljön, från ansökan på Mina sidor till beslut och utbetalning i Lifecare, och alla funktioner i listan är byggda eller levererade. Det som återstår är att verifiera regelverket systematiskt, variant för variant. Det gör verksamheten under hösten.
Veckans stora händelse var en helomvändning mitt i sprinten. I stället för att en robot skulle utföra stegen i Lifecare läser och skriver Rakel nu direkt i Lifecare: det officiella API:et där det räcker och det interna API:et för det handläggaren gör. Beslutet togs den 23 september, och roboten tas inte i produktion. På fredagen flyttade kopplingen från gränssnittet till backend och Lifecare-integratorn. Hur komponenterna samverkar visas i processkartan för återansökan under Funktionslista.
5 arbetsdagar · 6 repon · 340 commits
Under fem arbetsdagar gjordes 340 commits i sex repon: api-service-caremanagement (151), web-app-drakel (141), api-service-operaton (20), api-service-lifecare-integrator (13), web-app-business-center (10) och RPA-Drakel (5). Vid sprintens start stod tolv funktioner som ej påbörjade eller blockerade. Vid slutet är ingen punkt kvar: av 94 poster är 44 levererade, 47 byggda mot spec och väntar på verifiering, och 3 har utgått efter verksamhetens svar.
Stänga frågor · färdigställa · verifiera
1. Stänga öppna frågor och regelverk. Flera frågeomgångar besvarades under veckan: icke-röda dagar och midsommarafton, förskott på förmån, beslutsfattaren, barnens inkomster och vad "föregående månad" betyder. De flesta andra frågor är parkerade och behöver svar före produktion.
2. Färdigställa kvarvarande funktioner. Alla tolv funktioner som stod som ej påbörjade eller blockerade är nu byggda eller levererade.
3. End-to-end-verifiering mot riktig data. Flödet kördes mot Lifecare i testmiljön, och fredagen ägnades åt end-to-end-tester av nyansökan och tilläggsansökan. Verksamheten testade och hittade fel som rättades samma dag. Regelverket behöver fortfarande testas i alla kombinationer, med SSBTEK-testdata som verksamheten själv kan styra.
Vad teamet tar med sig och planen framåt finns under Retrospektiv.
Vad teamet tar med sig
Retrospektivet hölls efter sprintens slut. Det är sammanställt i tre delar: vad som bar sprinten, vad som behöver finnas på plats nästa gång, och de lärdomar vi tar med oss. (Retron från innovationsdagarna 5–7 maj är dokumenterad separat och inkorporerad i hur Fas 0 och Insikt 02 är formulerade.)
- Högt i tak och öppen dialog — inga dumma frågor, alla vågade dela tankar och idéer
- Tvärfunktionellt team i samma rum (närhetsprincipen), med stort beslutsmandat hos verksamheten
- Snabb återkoppling från verksamheten och snabba API-justeringar vid behov
- Högt tempo och starkt driv — alla med och drog åt samma håll
- Förberedda miljöer och fullt fokus: heltid på uppgiften, innovationsdagarna gav fart från start
- AI till allt — "hade inte gått utan"; många commits och funktioner på kort tid
- Två veckor gav utrymme att tänka och återkomma — utan att bli för stressigt
- Riktigt verksamhetssystem och API:er att integrera mot (Lifecare, SSBTEK, RPA) — mindre mockat
- Tillgång till alla ingående delar redan innan start: API:er, systemet och en arkitekt nära
- En helhetskarta över flödet och hur tjänsten hänger ihop med andra system, innan sprinten
- Grund för hur verksamheten arbetar idag, grundmallar (dokument/journaler) och styrande designprinciper
- En yta/whiteboard för att snabbt fånga idéer och frågor i högt tempo
- Bättre koordination av parallella AI-sessioner (delade trådar krockade ibland)
- Andningsutrymme för reflektion mitt i, och samma resurser hela vägen genom projektet
Lärdomar vi tar med oss
- Rätt personer på rätt plats är avgörande — arbetssättet är kraftfullt men passar inte alla personer eller situationer.
- AI som hävstång: AI + nära verksamhet + fokuserad utveckling åstadkommer förvånansvärt mycket. Automatisera återkommande moment (egna "skills") och låt AI jobba direkt mot frontend.
- Skriv ner i tempot: i 200 % fart tappas frågor och beslut om de inte fångas direkt.
- Verksamheten visar, inte bara förklarar — det minskar kommunikationsmissarna mellan verksamhet och utvecklare.
- Allt går inte att förbereda — en del måste få växa fram under tiden, och intensiva veckor kräver inplanerad återhämtning.
Vad teamet tar med sig från uppföljningssprinten
Retrospektivet hölls fredagen den 25 september, direkt efter demon. Svaret på frågan från start är i stort sett ja. Det riktiga verksamhetssystemet och de riktiga API:erna fanns på plats, regelverket var förberett i samma tabellform som regelmotorn använder, och det var samma personer som i juni. Teamet gav veckan nio av tio, kanske nio och en halv. Det som återkommer från förra gången är svårigheten att hålla koll på frågor och beställningar i högt tempo.
- Lika roligt som förra gången. Intensivt men roligt, med god stämning och plats för att ha lite kul
- Stort engagemang från verksamheten, som vet hur den vill arbeta. Lång erfarenhet av den gamla Rakel och av robotar, beslutsmandat och ingen rädsla för förändring gjorde att verksamheten vågade säga hur det ska vara
- Helomvändningen. Förslaget att släppa roboten kom, beslutet togs utan tvekan och teamet körde på det. Det kostade fart för stunden men lönade sig: veckan nådde dit den skulle, och ett ärende har testats hela vägen
- Samma personer som i juni. Kunskapen om processen fanns redan, och ingen tid gick åt till att lära känna nya
- God förberedelse. Regelverket var genomgånget på handläggarmöten och skickat i förväg, i den tabellform regelmotorn förväntar sig
- Kollegor från verksamheten på plats. Färre frågor behövde tas hem, beslut kunde fattas direkt och ingen satt ensam med normberäkningen
- En vecka räckte den här gången. Uppgiften var att ta ställning till det som fanns, inte att bygga från grunden
- En lokal som inspirerar. Rummet var skönt att ha för sig själva, men saknade fönster
- Utvecklingsmiljöer som fungerar. Kommunens datorer och nät begränsar utvecklingen, och delar av infrastrukturen går inte att nå därifrån
- Tid för strukturerade tester av regelverket. Funktionerna fungerar, men varje regel måste testas i alla kombinationer. Det görs bäst i lugn och ro, inte mitt i sprinten
- Testdata för SSBTEK som verksamheten själv kan styra. Regelverket bygger på SSBTEK:s data, men testmiljön ger samma svar för alla. En mall, till exempel ett kalkylblad med inkomstbelopp per månad, skulle låta verksamheten pröva varje variant, och scenarierna kan sedan köras automatiskt
- Bättre koll på frågor och beställningar. I högt tempo är det svårt att följa vad som skickats, vad som är gjort och vilka svar som kommit. Frågor samlade i ett dokument fungerade bättre än lösa kort i chatten, och en AI som håller backloggen utifrån chatten vore en hjälp
- Ett kort förmöte veckan innan, en halvtimme om målbilden och vad alla gjort sedan sist, så att måndagen inte blir diffus. Och ännu mer tid att förbereda regelverket
- Tid för en gemensam lunch. Flera hoppade över luncherna för att hinna
Lärdomar vi tar med oss
- En verksamhet på plats som vet vad den vill gör det snabbt. Jämfört med projekt där verksamheten inte är på plats går det här betydligt fortare.
- Våga vända. Ett tydligt beslut som fattas snabbt kostar mindre än att fortsätta på fel spår.
- Kort sprint, sedan paus. När grunden finns utnyttjar en vecka följd av tid för verifiering och en uppsamling tiden bättre än två veckor i sträck.
- AI går fort men kräver kontroll. Det är lätt att tappa överblicken, och AI känner inte alla robotens aktiviteter. Koden behöver fortfarande granskas av människor. Automatisk granskning hittar mycket, men inte allt.
Plan framåt
Nästa steg är att verksamheten testar det som byggts och att teamet rättar det som kommer upp. Takten blir lugnare än under sprinten, eftersom verksamheten har mycket arbete inför Lifecare.
- Oktober–november: verksamheten testar allt. Alla ansökningsflöden och varianter: nyansökan, återansökan och tilläggsansökan, med de obligatoriska kontrollerna påslagna. Alla texter och PDF:er. Varningarna och regelverket i processmotorn. Varje flik: finns det data som kan sållas bort?
- Uppsamling i början av december. Ett möte, eller en dag där alla är uppbokade, för att gå igenom det som kommit upp. Gränssnittsjusteringar kan rättas direkt med snabb återkoppling. Flödesfrågor rättas och verifieras igen. Mötet bokas så snart som möjligt.
- Fram till dess städar teamet i koden, och verksamheten skickar in det den vill ha ändrat.
- Parkerade frågor. De flesta frågorna från veckan är parkerade, men de behöver svar innan lösningen går i produktion.
- Inför produktion behövs miljöer, brandväggsöppningar och minst tre behörighetsgrupper: handläggare, mallar och texter samt logguppföljning.
- Handläggarens egen inloggning mot Lifecare. Den ska ersätta det gemensamma kontot, så att det syns vem som sparat ett beslut. Säkerheten ska vara lika hög som i Lifecare, eftersom det är samma känsliga information, även om det kan betyda en extra inloggning.
- Informationssäkerhet. Det är inte beslutat hur information i den högsta skyddsklassen ska hanteras, och det måste vara klart innan lösningen används på riktiga personer. Att slå upp riktiga personer i SSBTEK kräver ett beslut av ledningen om vad som är tillåtet.
- Produktionssättning. Lifecare införs i slutet av april. Första månaden finns inga normberäkningar eller beslut i Lifecare att bygga på. Återansökans förifyllnad och rekommendationer fungerar därför först andra månaden. Det behöver planeras hur ansökan ska guidas under den tiden och när Mina sidor öppnar.