Problemet är inte att avvikelser inträffar — det är att vi inte lär oss av dem
En avvikelse kan vara att en brukare fått sin medicin fem minuter för sent, eller att något gick fel i bemötandet mellan personal och brukare. Bedömer personalen att händelsen är så allvarlig att den i högre grad riskerar brukarens hälsa rapporteras den i stället som ett missförhållande. Var gränsen går finns det inga exakta kriterier för — det är personalens bedömning i stunden som avgör.
Själva händelsen hanteras nästan alltid på plats, direkt när den inträffar. Rapporteringen finns till för något annat: att dokumentera, att i efterhand utreda vad som hände, och att förebygga att det händer igen. Det sista fungerar bara om informationen går att se på aggregerad nivå. Det är där dagens system, Flexite, går sönder.
- Komplex process för personalen att registrera avvikelser
- Ingen återkoppling till den rapporterande personalen
- Svårt att överblicka var i processen ärendena befinner sig
- Ärenden faller mellan stolarna
- Ärenden blir liggande
- Svårt att upptäcka mönster och problem
- Svårt att bedriva verksamhetsutveckling för att minska antalet missförhållanden
- Rapportering som går att göra i direkt anslutning till händelsen
- Rapportören får veta vad som hände med ärendet
- Tydligt var i processen ett ärende står och vem som äger det
- Ärenden som inte kan bli liggande obemärkt
- Samlad information som gör mönster och problem synliga
- Underlag som går att arbeta förebyggande med, inte bara arkivera
Draken ersätter Flexite och körs inom två förvaltningar: Vård- och omsorgsförvaltningen (VoF) och Individ- och arbetsmarknadsförvaltningen (IAF). Arbetet är redan förankrat — arbetsgruppen gav klartecken på ärendeprocessen den 1 juni 2026 och på verksamhetsuppföljningen den 1 juli. Sprinten bygger vidare på det. Vi börjar inte om.
Enkel rapportering plus verklig återkoppling ger underlaget som saknas
Om rapportering blir enkel nog att göra direkt vid händelsen, och rapportören faktiskt får veta vad som hände sedan, då ökar både antalet rapporter och deras kvalitet — och först då finns underlaget som krävs för att se mönster och arbeta förebyggande.
Sprinten ska pröva den kedjan, inte bara bygga formulär. Håller hypotesen inte, är det ett resultat värt att veta redan efter tio dagar.
Så funkar en innovationssprint
En innovationssprint är ett tvåveckors arbetssätt för att utveckla digitala tjänster snabbare, närmare verksamheten och med AI som motor genom hela processen. Det bygger på tre saker: tvärfunktionella team, direktkontakt med verksamheten, och att vi arbetar hypotesdrivet i stället för kravdrivet.
Skillnaden mot vanligt projektarbete är att avstånden är borta. Det finns inga mellanlager som filtrerar eller fördröjer information, ingen kravspecifikation som beskriver varje detalj i förväg, och ingen nästa sprint att skjuta saker till. Vi bygger, visar, lär och justerar — varje dag.
Vi bygger för att lära, inte för att leverera en färdig produkt. Prototypen validerar innan vi investerar resurser.
Tre faser per sprint
Prototypen byggs tillsammans med verksamheten, arkitekturdialogen förs, och deploy-kedjan till testbädden ställs på plats. Här bestäms också hur verksamheten ska vara involverad under sprinten — inte om.
Daglig standup som nav, demo av ny funktionalitet, direktdialog med verksamheten och löpande deploy till testbädd. Det som byggs idag ska gå att titta på imorgon.
Resultatet utvärderas mot den ursprungliga hypotesen, lärdomarna dokumenteras och processmodellen förfinas. Kunskapen förs över — den stannar inte i teamet.
Två sprintar, en tråd
Draken körs som två sprintar om tio arbetsdagar vardera, med tre veckors mellanrum. Det är ett medvetet val: den andra sprinten ska bygga på vad vi faktiskt lärde oss av den första, inte på en plan skriven i augusti.
- Rapportering och ärendemodell
- Flödet som enhetschefen äger
- Ett ärende hela vägen: inrapportering till avslut, för ett spår
- LEX-flödet
- MAS/MAR:s parallella HSL-utredning
- Behörighetsstyrning mellan förvaltningarna
Uppehållet är inte en paus
Det är där verksamheten hinner testa det som byggts i sprint 1 på riktigt, och där återkopplingen samlas ihop. Det som kommer tillbaka därifrån är det som styr sprint 2.
För dig som deltagare betyder det två saker: allt du inte hinner i sprint 1 blir inte automatiskt sprint 2:s problem, och det du byggt kan mycket väl behöva göras om när verksamheten sagt sitt. Båda delarna är meningen.
Standupen håller ihop sprinten
Varje dag, 15–30 minuter. Det är sprintens enda fasta möte, och det är där riktningen justeras. Kom förberedd — standupen är inte platsen där du börjar tänka på vad du gjorde igår.
Genomgång av igår
Status och framsteg. Kort och konkret: vad blev gjort, vad blev det inte.
Demo av ny funktionalitet
Visa det som byggts sedan sist och få direktfeedback från verksamheten. Halvfärdigt duger — det är hela poängen.
Frågor, hinder & synk
Blockeringar och tekniska val lyfts här, inte i en tråd tre dagar senare.
Sex saker som gör sprinten till en sprint
Noll avstånd
Inga mellanlager mellan verksamhet och utveckling.
Snabba leveranser
Korta cykler och daglig feedback.
Tvärfunktionellt
Ett team som täcker alla kompetenser som behövs.
AI-accelererat
AI som verktyg genom hela processen, inte bara i kodandet.
Hypotesdriven
Prototypen validerar innan resurser investeras.
Löpande anpassning
Processen utvecklas under sprintens gång.
Vad som händer när sprinten är slut
Resultatet vägs mot hypotesen, och beslutet blir ett av två. Båda är giltiga utfall — en sprint som avbryts efter tio dagar med tydliga lärdomar är billigare än ett projekt som drivs vidare på hoppet.
- Uppskalning och produktionssättning
- Det som byggts vidareutvecklas mot skarp miljö
- Lärdomarna dokumenteras för framtida initiativ
- Vi vet varför det inte höll — och slipper göra om misstaget
Vad innebär det att delta i en utvecklingssprint?
Att delta i en sprint ä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
Tio arbetsdagar är inte mycket. Det som inte händer idag, händer kanske aldrig.
En tvåveckorssprint har ingen buffert. 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.
Att vi kör två sprintar gör inte den första mindre viktig
Det ligger nära till hands att tänka att det som inte hinns med i sprint 1 tas i sprint 2. Så fungerar det inte. Sprint 2 har sitt eget innehåll — LEX-flödet, HSL-utredningen och behörighetsstyrningen — och den bygger dessutom på att grunden från sprint 1 sitter.
Uppehållet i v.38–39 är till för att verksamheten ska hinna testa och ge återkoppling. Det är inte extra utvecklingstid, och det är inte en plats att parkera saker på.
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.
Räkna särskilt med det efter uppehållet. När verksamheten testat sprint 1:s resultat på riktigt kommer saker att behöva göras om. Det är precis vad uppehållet är till fö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 sprint 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 det dyraste misstaget i en sprint.
Alla roller är jämlika under sprinten
Under sprinten finns inga hierarkier. En enhetschefs eller LEX-utredares 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 sprintar 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.
Vad som ska byggas
Listan är sammanställd ur avvikelseprocessen i Confluence och ur överlämningsspecen för demo-prototypen. Den är sprintens arbetsdokument — den uppdateras löpande, och varje rad går att fälla ut för acceptanskriterier och källa.
Prototypen räknas inte som levererad. Den visar riktningen och är förankrad med verksamheten, men den saknar backend och nollställs vid omladdning. Allt ska byggas i riktig miljö, och därför står i princip allt som ogjort vid sprintstart. Undantaget är registreringsformuläret, som i huvudsak finns på plats.
-
RAP-01 Registrera avvikelse eller missförhållande Rapportören väljer rapporttyp vid registrering. Valet styr hela det fortsatta flödet. Formuläret finns i huvudsak — behöver kopplas till skarp backend
Acceptanskriterier- Rapporttyp Avvikelse eller Missförhållande sätts som label på ärendet
- Endast personal kan rapportera — anhörigas synpunkter hör till synpunktsprocessen
- Ärendetypen blir
DEVIATIONi SupportManagement
Regel: det finns inga exakta kriterier för vad som är ett missförhållande. Det är den enskilda personalens bedömning i stunden som avgör. Gränssnittet ska stödja bedömningen, inte försöka avgöra den.Källa: Confluence sida 2 & 5 · prototypspec §6
-
RAP-02 Val av förvaltning vid dubbel anställning Är rapportören anställd i både VoF och IAF måste förvaltning väljas innan ärendet kan skickas.
Acceptanskriterier- Organisationstillhörighet hämtas från Employee API
- Tillhör personen bara en förvaltning väljs den automatiskt
- Valet avgör vilket namespace ärendet hamnar i
Källa: Confluence sida 3 & 4
-
RAP-03 Beskrivning av händelsen och inblandade parter Fritextbeskrivning plus brukare och eventuella andra inblandade — personer, personal, lokaler, rutiner eller processer. Finns i formuläret — datamodell och lagring kvarstår
Acceptanskriterier- Ärendeägaren benämns Brukare i gränssnittet och lagras som
PRIMARY - Ett ärende kan kopplas till flera parter samtidigt
- Omedelbara åtgärder som redan vidtagits går att ange direkt
Källa: Confluence sida 2 & 3 · prototypspec §6
- Ärendeägaren benämns Brukare i gränssnittet och lagras som
-
RAP-04 Plats för händelsen Plats sätts från rapportörens egen placering som förval, eller pekas ut manuellt bland de platser som hör till förvaltningen.
Acceptanskriterier- Förvalt värde hämtas via Employee API
- Vid utpekning söks platser via MDViewer API (
GET /{orgId}/orgtree) - Rapportörens förvaltning avgränsar vilken del av organisationsträdet som visas
- Platsen avgör vilken enhetschef ärendet tilldelas
Förenkling: enhet och plats behandlas som samma sak i behörighetsmodellen.Källa: Confluence sida 4 & 7
-
RAP-05 Adress som förstärkning av plats Där platsangivelsen inte räcker för att förstå var händelsen inträffade kan en adress läggas till.
Acceptanskriterier- Adressfältet är valfritt
- Bedöms främst behövas för VoF Hemtjänst, där platsen är ett område snarare än en byggnad
Källa: Confluence sida 4
-
RAP-06 Rapportera åt annan personal När en person rapporterar på någon annans uppdrag registreras den andra personen som kontaktperson.
Acceptanskriterier- Kontaktpersonen lagras som
CONTACT - Den som skickat in ärendet är fortfarande den som ser det på Mina sidor
Källa: Confluence sida 3
- Kontaktpersonen lagras som
-
RAP-07 Mina sidor i Katla Rapportören kan följa sitt eget ärende: ärendenummer, status och meddelanden. Detta är den återkoppling som helt saknas i Flexite.
Acceptanskriterier- Rapportören ser endast sina egna ärenden
- Aktuell status visas i begriplig svenska, inte som statuskod
- Meddelandetråden är tillgänglig från ärendet
Varför den här raden finns: "ingen återkoppling till den rapporterande personalen" är en av de sju uttalade bristerna med dagens system. RAP-07 är svaret på den.Källa: Confluence sida 1 & 4
-
RAP-08 Rapportören ser endast sina egna uppgifter Utredningsmaterial, bedömningar och interna kommentarer visas aldrig för rapportören — bara de fält hen själv fyllt i.
Acceptanskriterier- Filtreringen sker i frontend enligt nuvarande lösningsförslag
- Fältnivåbehörighet inne i ett ärende är uttalat utanför omfattningen för v1
Källa: Confluence sida 4
-
RAP-09 Inskickade uppgifter kan inte ändras Det rapportören skickat in är låst. Rättelser sker genom komplettering och meddelanden, inte genom redigering.
Acceptanskriterier- Gäller även handläggare — de inskickade fälten är read-only i Draken
- Handläggaren kan däremot rätta kontextstyrda uppgifter som plats och kategorisering (se FLO-09)
Källa: Confluence sida 3
-
RAP-10 Meddelandetråd mellan Katla och Draken Handläggaren kan ställa frågor till rapportören och rapportören kan svara, i en tråd som hänger på ärendet.
Acceptanskriterier- Tråden är synlig för rapportören på Mina sidor och för handläggaren i Draken
- Begärd komplettering sätter ärendet i
AWAITING_RESPONSE
Källa: Confluence sida 3 & 6
-
MOD-01 Ärendetyper Tre typer definierade för avvikelsehantering: avvikelseärende, åtgärdsärende och LEX-ärende.
AcceptanskriterierDEVIATION— avvikelseärendeACTIONS— åtgärdsärendeLEX— LEX-ärende
Källa: Confluence sida 4
-
MOD-02 Ursprungstypen är oföränderlig Kom ärendet in som avvikelse förblir det en avvikelse i typ och visning, även om det senare bedöms som missförhållande.
Acceptanskriterier- Rapportörens ursprungliga taggning lagras separat och skrivs aldrig över
- LEX-ansvarig kan ange om typen stämmer eller inte — men det ändrar inte ursprungstypen
- Eskalering till missförhållandeflödet styrs av en egen flagga, inte av typbyte
Beslutad regel: ursprungstypen styr. LEX-ansvarigs bedömning av om det verkligen är ett missförhållande dokumenteras som ett eget beslut, inte som en omtaggning. Det är därför en avvikelse och dess eskalering behöver hållas isär i datamodellen.Källa: beslut i planeringen · prototypspec §8 regel 1 & 4
-
MOD-03 Lagrum på ärendet Ett ärende omfattas av ett eller flera lagrum: HSL, SOL eller LSS. Lagrummet styr inte behörighet, men är avgörande för utredarna.
Acceptanskriterier- Lagrummen lagras under ärendets properties
- Urvalet av tillåtna lagrum behöver lagras någonstans — ny konfigurationsresurs är föreslagen
Källa: Confluence sida 4 & 5
-
MOD-04 Två separata riskvärden Risk redovisas alltid uppdelat: ett riskvärde för HSL-delen och ett för SOL/LSS-delen, aldrig sammanslaget.
Acceptanskriterier- Två fält på ärendet, skala 1–9
- Uppdelningen följer med genom hela systemet: fält, tabellkolumner, filter och aggregat
- HSL-riskvärde 4 eller högre triggar MAS/MAR (se HSL-01)
Regel som inte får brytas: risk presenteras alltid uppdelat HSL mot SOL/LSS. Prototypen har ett äldre sammanslaget fält som medvetet lämnats vilande — det ska inte återanvändas.Källa: Confluence sida 5 · prototypspec §8 regel 5
-
MOD-05 IVO-anmälan och polisanmälan som egenskaper Att ett ärende anmälts till IVO eller är föremål för polisanmälan noteras på ärendet och går att följa upp på.
Acceptanskriterier- Båda är filtrerbara i verksamhetsuppföljningen
- Själva IVO-anmälan upprättas utanför Draken men noteras på ärendet (se INT-07)
Källa: Confluence sida 2 · prototypspec §6
-
MOD-06 Organisations- och platsinformation som id Förvaltning, verksamhet, enhet och plats lagras som identifierare, inte som fritext, så att de går att aggregera på.
Acceptanskriterier- Övrig kontextinformation lagras som labels på ärendet
- Visningsnamn härleds från id vid presentation
Källa: Confluence sida 4
-
MOD-07 Persistens i SupportManagement Ärenden lagras i mikrotjänsten SupportManagement. Prototypen har ingen lagring alls — allt nollställs vid omladdning.
Acceptanskriterier- Ärendet sparas efter att kontextstyrda uppgifter berikats
- Utökningar av datamodellen behöver kartläggas — uttalad öppen fråga
Detta är den största enskilda skillnaden mot prototypen. Allt som i demon ser färdigt ut bygger på state i minnet. Utan MOD-07 fungerar ingenting på riktigt.Källa: Confluence sida 4 · prototypspec §2 & §11
-
MOD-08 Tidsstämplar för statusövergångar Varje statusbyte tidsstämplas, inte bara registreringstillfället. Utan det går ingen statistik om handläggningstid att ta fram.
Acceptanskriterier- Möjliggör "ärenden som fastnat i utredning" och mätning av LEX-utredningens längd
- Krävs för aviseringen om stillastående ärenden (se NOT-03)
- Krävs för lägeskortet "ej påbörjade ärenden över 30 dagar" (se UPF-03)
Prioriterad datamodellutökning. Tre andra funktioner i den här listan är beroende av MOD-08. Den bör tas tidigt.Källa: prototypspec §11
-
MOD-09 Kopplade ärenden Ärenden som rör samma brukare hittas automatiskt, och handläggaren kan dessutom koppla ihop ärenden manuellt.
Acceptanskriterier- Automatisk matchning på brukarens personnummer, delat i pågående och avslutade
- Manuell koppling för ärenden som rör en annan brukare
- Koppling går att bryta
Källa: prototypspec §6
-
KAT-01 HSL-kategorier med undertyper Tretton kategorier inom hälso- och sjukvårdslagen, flera med undertyper — Läkemedel har tio, Fall har fyra, Trycksår har fyra grader.
Acceptanskriterier- Kategorierna lagras som labels av typen kategori och undertyp
- Kategorier utan undertyper går att välja direkt
- Fullständig taxonomi finns i Confluence — den ska inte skrivas av för hand i koden
Källa: Confluence sida 5
-
KAT-02 SOL/LSS-kategorier Nio kategorier — från brister i arbetssätt och bemötande till ekonomiska, fysiska, psykiska och sexuella övergrepp.
Acceptanskriterier- Samma label-struktur som HSL-kategorierna
- Undertyper finns för sex av de nio
Källa: Confluence sida 5
-
KAT-03 Kategorityper låsta till lagrum En HSL-kategori går bara att välja om ärendet omfattas av HSL. Systemet ska förhindra kombinationer som inte finns.
Acceptanskriterier- Valbara kategorier filtreras utifrån valda lagrum
- Ändras lagrummen ska redan valda kategorier valideras om
Källa: Confluence sida 5
-
KAT-04 Enhetschefen kategoriserar avvikelser Kom ärendet in som avvikelse är det enhetschefen som kategoriserar och väljer lagrum — även om ärendet senare eskaleras till LEX.
Acceptanskriterier- Kategoriseringen görs i enhetschefens utredning
- LEX omkategoriserar inte ett eskalerat ärende — kategoriseringen finns redan
Beslutad regel: ursprungstypen avgör vem som kategoriserar, inte var ärendet råkar befinna sig i flödet. Se MOD-02.Källa: beslut i planeringen · prototypspec §8 regel 4
-
KAT-05 LEX-utredaren kategoriserar rapporterade missförhållanden Kom ärendet in som missförhållande sker kategoriseringen i stället i SOL/LSS-utredningen.
Acceptanskriterier- Enhetschefens kategoriseringssektion visas inte för rapporterade missförhållanden
- Lagrumssektionen är helt dold — SOL/LSS sätts automatiskt i bakgrunden
Källa: Confluence sida 5 · prototypspec §8 regel 4
-
KAT-06 Tillåtna lagrumskombinationer vid avvikelse Enhetschefen väljer bland sex kombinationer: HSL+SOL, HSL+LSS, LSS+SOL, eller HSL, SOL respektive LSS var för sig.
Acceptanskriterier- Endast dessa sex kombinationer är giltiga — övriga ska inte gå att spara
- Lagrummet kan ha ett 1:1-förhållande till kategoriseringen och bör kunna föreslås automatiskt
Källa: Confluence sida 2 & 5
-
KAT-07 SOL/LSS forceras vid missförhållande Ett ärende som rapporterats som missförhållande får automatiskt lagrummen SOL/LSS, och de går inte att ändra.
Acceptanskriterier- Sätts vid registrering, inte vid utredning
- Lagrumsvalet döljs helt i gränssnittet för dessa ärenden
Källa: Confluence sida 2 & 5
-
KAT-08 Delad orsaksmodell Fem orsaksområden och sex bakomliggande orsaker återanvänds i både SOL/LSS-utredningen och HSL-utredningen.
Acceptanskriterier- Orsaksområden: kommunikation och information · omgivning och organisation · procedurer, rutiner och riktlinjer · teknik, utrustning och apparatur · människa, kunskap och kompetens
- Bakomliggande orsaker: brist i kommunikation · tidsbrist eller arbetsbelastning · kunskapsbrist · rutin saknas eller följs inte · tekniskt fel · övrigt
- Modelleras en gång och återanvänds — inte kopieras per utredningstyp
Källa: Confluence sida 5
-
KAT-09 Femgradig skala för missförhållande Samma skala används både för utredarens förslag och för LEX-ansvarigs beslut. De två högsta graderna innebär IVO-anmälan.
Acceptanskriterier- Inget missförhållande · påtaglig risk för missförhållande · missförhållande · påtaglig risk för allvarligt missförhållande (IVO) · allvarligt missförhållande (IVO)
- Förslag och beslut lagras som två skilda värden — beslutet ersätter inte förslaget
- De två IVO-graderna ska tydligt markeras i gränssnittet
Källa: Confluence sida 5 · prototypspec §6
-
KAT-10 Taxonomin lagrad som konfiguration Kategorier, lagrum, orsakslistor och åtgärdstyper behöver kunna ändras utan kodändring.
Acceptanskriterier- En resurs för generisk konfiguration är föreslagen, som JSON med JSON-schema
- Öppen fråga: kan befintlig metadata-resurs i SupportManagement användas, eller behövs en ny?
Källa: Confluence sida 4
-
FLO-01 Statusmodellen Sex statusar i linjär följd, förankrade med verksamheten: inkommit, under granskning, under utredning, under beslut, under uppföljning, avslutat.
AcceptanskriterierNEW·REVIEW·INQUIRY·DECISION·FOLLOW_UP·SOLVED- Samma statusar används i båda förvaltningarna — gränssnittet är gemensamt
- Statuskoder visas aldrig för användaren, bara de svenska benämningarna
Beslutad regel: den här listan gäller. Verksamheten har medvetet tagit bort statusar som bedömdes onödiga eller förvirrande, och prototypens fasnamn (incoming,reviewing,investigating…) ska rättas till dessa. En äldre statuslista finns kvar i Confluence och bör uppdateras så att ingen bygger mot fel modell.Källa: Confluence sida 6 (ersätter sida 4) · beslut i planeringen
-
FLO-02 Sidolägena komplettering och tilldelat Två statusar som kan inträffa när som helst utan att flödet går framåt: begärd komplettering och tilldelning mellan roller eller enheter.
AcceptanskriterierAWAITING_RESPONSEnär handläggaren begär komplettering av rapportörenASSIGNEDnär ärendet tilldelas mellan roller eller enheter- Båda saknas helt i prototypen och måste byggas
Källa: Confluence sida 6
-
FLO-03 Progress-stege som visar var ärendet står Aktuell status visas som ett steg i en synlig följd, så att både handläggare och rapportör ser var i processen ärendet befinner sig.
Acceptanskriterier- De sex linjära statusarna bildar stegen; sidolägena visas som avvikelse från stegen
- Öppen fråga i underlaget: är en stege motiverad alls med så få statusar?
Varför den här raden finns: "svårt att överblicka var i processen ärendena befinner sig" är en av de sju bristerna med Flexite.Källa: Confluence sida 1, 4 & 6
-
FLO-04 Återgång efter komplettering När kompletteringen kommit in ska ärendet tillbaka till den status det hade innan — inte till början.
Acceptanskriterier- Föregående status måste finnas tillgänglig och tillförlitlig
- Ett fält för föregående status finns i SupportManagement men exponeras inte i API:et, och sätts inte konsekvent — kodanalys krävs
Känt hinder. Den här raden kan visa sig kräva en ändring i SupportManagement snarare än i Draken. Bör undersökas tidigt.Källa: Confluence sida 4
-
FLO-05 Tilldelning utifrån plats Ärendet går automatiskt till den enhetschef som ansvarar för den plats rapportören angett, och chefen blir intressent på ärendet.
Acceptanskriterier- Ansvarig chef för en enhet hittas via DataWarehouseReader API
- Funktionen för att hitta enhetens chef är under utveckling (
DRAKEN-2825) - En enhetschef kan ansvara för flera enheter — anta aldrig en enda
Källa: Confluence sida 4 · prototypspec §5
-
FLO-06 Automatisk tilldelning till LEX-ansvarig efter sju dagar Vid rapporterat missförhållande har enhetschefen sju dagar att komplettera. Sedan går ärendet vidare av sig självt.
Acceptanskriterier- Sker automatiskt om ärendet inte redan tilldelats manuellt
- Mailavisering skickas vid tilldelning (se NOT-01)
- Inom IAF är det verksamhetschefen som är LEX-ansvarig och därmed mottagare
Varför den här raden finns: "ärenden blir liggande" och "ärenden faller mellan stolarna" är två av de sju bristerna. FLO-06 är mekanismen som förhindrar det.Källa: Confluence sida 2, 3 & 7
-
FLO-07 Eskalering vid misstänkt missförhållande Ser enhetschefen under utredningen att ett missförhållande kan föreligga eskaleras ärendet — utan att ursprungstypen ändras.
Acceptanskriterier- Eskaleringen är ett manuellt steg som chefen tar
- Ärendet går till LEX-ansvarig, som fördelar vidare till LEX-utredare
- Typen förblir Avvikelse i lista och metadata — bara flödet ändras
- Verksamhetschef blir valbar som mottagare vid eskalering
Fallgrop värd att känna till: i prototypen fanns en bugg där ärenden som eskalerats inte kunde tas vidare till beslut, eftersom flödeslogiken bara tittade på ursprungstaggningen. Lösningen var en enda delad kontroll som alla flödeskomponenter använder. Bygg om den kontrollen en gång, inte per vy.Källa: Confluence sida 2 · prototypspec §8 regel 1
-
FLO-08 LEX-ansvarigs initiala bedömning Tre möjliga utfall: anmäl direkt till IVO, bedöm att det inte är ett missförhållande, eller låt utreda.
Acceptanskriterier- Besluta om IVO-anmälan direkt och tilldela utredare
- Bedöma att händelsen inte är ett missförhållande och lämna tillbaka till enhetschef — ovanligt, men räknas som ett beslut och ska dokumenteras som ett
- Besluta att ärendet ska utredas och tilldela LEX-utredare
- Bedömningen är redigerbar endast för LEX-ansvarig; övriga roller ser den skrivskyddad
Källa: Confluence sida 2 · prototypspec §8 regel 3
-
FLO-09 Rätta ärenden som hamnat fel Handläggaren kan ändra plats, kategorisering eller förvaltning om något blivit fel vid registreringen.
Acceptanskriterier- Ändras plats eller förvaltning måste alla kontextstyrda egenskaper räknas om — inklusive behörighet och intressenter
- Rapportörens egna inskickade fält förblir låsta (se RAP-09)
Källa: Confluence sida 4
-
FLO-10 Spärr mot avslut när utredning pågår Ett ärende får inte stängas medan MAS/MAR:s HSL-utredning pågår, eller innan deras åtgärdsförslag är hanterade.
Acceptanskriterier- Avslutsknappen är blockerad med en synlig förklaring, inte tyst inaktiverad
- Gäller även när enhetschefen är klar med alla sina egna delar
- Samma spärr gäller ohanterade åtgärder generellt
Regel: MAS/MAR arbetar parallellt och blir ofta klara efter enhetschefen. Att chefen känner sig färdig betyder inte att ärendet är det.Källa: Confluence sida 2 & 3
-
FLO-11 Återkoppling till rapportören innan avslut Enhetschefen ska återkoppla till den som rapporterade innan ärendet stängs. Det är ett steg i flödet, inte en artighet.
Acceptanskriterier- Återkopplingen syns för rapportören på Mina sidor i Katla
- Öppen fråga: ska återkopplingen vara ett tvingande steg innan avslut, eller enbart uppmanas?
Källa: Confluence sida 2
-
FLO-12 Enhetschefen får inte besluta i missförhållandeärenden Är ärendet taggat som missförhållande kan enhetschefen inte ta det till beslut — det måste gå via LEX-ansvarig.
Acceptanskriterier- Beslutssteget är inte tillgängligt för enhetschefen i dessa ärenden
- En varning visas i tidiga faser om ärendet ännu inte tilldelats LEX-ansvarig
Källa: Confluence sida 3 & 7
-
BEH-01 Rollmodellen Rapportör, enhetschef, verksamhetschef, LEX-ansvarig, LEX-utredare och MAS/MAR — med olika mandat och olika synlighet.
Acceptanskriterier- Rollkoder:
REPORTER·UNIT_MANAGER·HEAD_OF_OPERATIONS·LEX_RESPONSIBLE·MAR_MAS - Därtill parterna på ärendet:
PRIMARY(brukare) ochCONTACT(kontaktperson) - En läsande administratörsroll behövs, som aldrig kan handlägga
Källa: Confluence sida 3 · prototypspec §5 & §8 regel 7
- Rollkoder:
-
BEH-02 Två namespaces: VoF och IAF Förvaltningarna hålls åtskilda i backend medan gränssnittet är gemensamt. Ett ärende hör alltid till exakt en förvaltning.
Acceptanskriterier- Förvaltning avgörs av aktuellt namespace och finns även på ärendet
- Prototypen täcker endast VoF — IAF är helt obyggt
Systematisk lucka i prototypen. Allt som rör IAF finns bara i Confluence. Räkna inte med att demon säger något om hur IAF ska fungera.Källa: Confluence sida 3 & 4
-
BEH-03 AD-grupper för åtkomst Elva grupper behövs: en per roll och förvaltning, plus rapportörernas åtkomst till Katla.
Acceptanskriterier- Enhetschef, verksamhetschef, LEX-utredare, LEX-ansvarig och MAS/MAR — i VoF- och IAF-variant vardera
- Öppen fråga: ska rapportörsgruppen vara egen, eller öppen för alla med AD-inloggning med kontroll av förvaltningstillhörighet?
- Gruppmedlemskap kan hämtas via ActiveDirectory API vid behov
Källa: Confluence sida 4
-
BEH-04 Behörighetskod på ärendet Varje ärende får en behörighetskod som avgör vilka som får se det. Koden sätts av backend när ärendet sparas.
Acceptanskriterier- Koder knyts till labels i ett träd, där koden ärvs nedåt om ingen specifik anges
- Varje AD-grupp mappas till en eller flera koder med läs- eller läs/skrivrätt, vilket gör överlappande behörigheter hanterbara
- Öppna frågor: skapas koden i frontend eller i SupportManagement, vad valideras den mot, och vilka utökningar av databasmodellen krävs?
Kärnan i hela behörighetsarbetet. BEH-04 är den rad som flest andra rader i det här området hänger på. Den bör designas innan något byggs.Källa: Confluence sida 4
-
BEH-05 Dynamisk filtrering på plats och avdelning Där behörigheten inte kräver strikt uppdelning filtreras vyerna i stället utifrån användarens kontext vid inloggning.
Acceptanskriterier- Minskar behovet av att lagra och synka information om varje enskild användare
- Alternativen om detta inte godtas är dyrare: en synktjänst som kontinuerligt skannar AD, eller en administrationsvy där behörighet sätts manuellt vid varje chefsbyte
Källa: Confluence sida 4
-
BEH-06 Enhetschefens synlighet Ser ärenden för de enheter hen ansvarar för, inom sin egen förvaltning. En chef kan ha flera enheter.
Acceptanskriterier- Har chefen mer än en enhet ska enhetsfiltret finnas även för hen, och rubriken skrivas i plural
- Ser inte SOL/LSS-utredningen (LEX-fliken)
- Ser däremot HSL-utredningen, läsbart
Källa: Confluence sida 3 & 7 · prototypspec §5
-
BEH-07 Verksamhetschefens synlighet Ser alla ärenden inom förvaltningen för de enheter och chefer hen ansvarar för, och kan agera handläggare.
Acceptanskriterier- Är stöd i processen för enhetschefen, inte överordnad handläggare
- Ser HSL-utredningen men inte SOL/LSS-utredningen
- Ansvarsomfånget är begränsat till egna enheter — inte hela förvaltningen
Källa: Confluence sida 3 & 7
-
BEH-08 Tvärfunktionella roller ser hela förvaltningen LEX-ansvarig, LEX-utredare och MAS/MAR har ingen enhetsbegränsning alls.
Acceptanskriterier- Inga filter i grundläget — hela förvaltningens ärenden är synliga
- MAS/MAR ser dessutom båda förvaltningarna, eftersom samma personer arbetar i båda
Källa: Confluence sida 3 & 7
-
BEH-09 Förvalt filter "Mina ärenden" Eftersom de tvärfunktionella rollerna ser allt behöver de ett förmarkerat filter som visar just deras ärenden först.
Acceptanskriterier- Aktivt som grundläge, går att stänga av
- För MAS/MAR bygger det på prenumeration snarare än tilldelning, eftersom de inte är handläggare (se HSL-10)
- Ärenden som väntar på att en LEX-ansvarig ska plocka upp dem listas parallellt med de egna
Källa: Confluence sida 4 & 7
-
BEH-10 Inom IAF är verksamhetschefen LEX-ansvarig Förvaltningarna har olika rolluppsättning. I IAF bär verksamhetschefen LEX-ansvarigs mandat för sina egna enheter.
Acceptanskriterier- I IAF beslutar verksamhetschefen om missförhållande och grad, om IVO-anmälan, och tilldelar LEX-utredare
- Mandatet är begränsat till de enheter chefen ansvarar för — inte hela förvaltningen
- I VoF är LEX-ansvarig en egen roll utan enhetsbegränsning
Strukturell skillnad, inte ett undantag. Behörighetsmodellen måste bära att samma mandat sitter på olika roller i de två förvaltningarna.Källa: Confluence sida 2 & 3
-
BEH-11 Fliksynlighet per roll LEX-fliken och LEX-ansvarigs extra dragspel visas bara för de roller som har med dem att göra.
Acceptanskriterier- Vid missförhållande ser LEX-ansvarig, verksamhetschef, LEX-utredare och MAS/MAR LEX-fliken och det extra dragspelet
- Vid avvikelse ser enhetschefen varken LEX-fliken eller LEX-ansvarigs dragspel
- MAS/MAR ser LEX-fliken när HSL-riskvärdet är 4 eller högre
Källa: Confluence sida 7
-
BEH-12 Chefskap som extra kontroll Att en person faktiskt är chef härleds från personaldata, som skydd mot att en AD-grupp inte uppdaterats när någon slutat vara chef.
Acceptanskriterier- Hämtas via Employee API
- Används som komplement till AD-gruppen, inte i stället för den
Källa: Confluence sida 4
-
BEH-13 Läsande administratörsroll En roll som ser allt men aldrig kan handlägga, tilldela eller driva ärendet framåt.
Acceptanskriterier- Ser ärenden i alla faser, inklusive nya och sådana som tilldelats andra
- Åtgärdspanelen ersätts av en skrivskyddad informationsruta, och ärendevyn märks som skrivskyddad
- Ingår i verksamhetsuppföljningen fullt ut
Fallgrop från prototypen: eftersom alla ärenden startar i första fasen, och den vyn var hårdspärrad till handläggare, blev administratörens samtliga vyer tomma. Rollen måste uttryckligen inkluderas i listlogiken, inte bara ges läsrätt.Källa: prototypspec §8 regel 7
-
UTR-01 Enhetschefen äger utredningen Chefen inleder granskning och utredning, beslutar om åtgärder eller att avstå, och ansvarar för att ärendet fullföljs.
Acceptanskriterier- Chefen kan ta över ärendet och uppdatera intressenter
- Att besluta om ingen åtgärd är ett giltigt beslut som ska gå att dokumentera
- Chefen tar ärendet vidare till beslut och uppföljning
Källa: Confluence sida 2 & 3
-
UTR-02 Orsak till avvikelsen Chefen anger vilket orsaksområde avvikelsen hör till, ur den delade orsaksmodellen.
Acceptanskriterier- Samma orsaksområden som i utredningarna (se KAT-08)
- Orsaken är filtrerbar i verksamhetsuppföljningen
Källa: Confluence sida 5
-
UTR-03 Riskbedömning HSL Ett uträknat riskvärde för HSL-delen. Fyra eller högre gör att MAS/MAR aviseras och HSL-utredningen tänds.
Acceptanskriterier- Värdet räknas ut, inte gissas — beräkningsregeln behöver fastställas
- Sätts när ärendet omfattas av HSL
- Tröskeln 4 är den enda automatiska trigger som finns i HSL-spåret
Källa: Confluence sida 2 & 5
-
UTR-04 Riskbedömning SOL/LSS Motsvarande riskvärde för SOL/LSS-delen, redovisat separat från HSL.
Acceptanskriterier- Ett ärende kan ha båda riskvärdena satta samtidigt
- Prototypens testdata saknar helt ärenden med båda värdena — det behöver täckas av testfall
Källa: Confluence sida 5 · prototypspec §11
-
UTR-05 Misstänkt missförhållande En ja/nej-markering där chefen anger om utredningen pekar mot ett missförhållande. Den driver eskaleringen.
Acceptanskriterier- Markeringen ändrar inte ärendets typ (se MOD-02)
- Den öppnar däremot missförhållandeflödet: LEX-ansvarig, utredare och beslut
- Chefen fortsätter själv fylla i lagrum, orsak och kategorisering (se KAT-04)
Källa: Confluence sida 5 · prototypspec §8 regel 1 & 4
-
UTR-06 Chefens åtgärdsval Fyra åtgärdstyper står till enhetschefens förfogande: disciplinåtgärd, utbildning, översyn av rutin och övrig åtgärd.
Acceptanskriterier- Chefens lista skiljer sig från utredarnas sju typer — de ska inte slås samman
- Åtgärder kan läggas till både i utredning, beslut och uppföljning
Källa: Confluence sida 5
-
UTR-07 Sju dagar för komplettering vid missförhållande Är ärendet rapporterat som missförhållande har chefen sju dagar att utreda och komplettera innan det går vidare.
Acceptanskriterier- Fristen ska vara synlig för chefen, inte bara verka i bakgrunden
- Efter sju dagar sker tilldelningen automatiskt (se FLO-06)
- Chefen kan tilldela manuellt tidigare
Källa: Confluence sida 2 & 3
-
LEX-01 LEX-fliken En egen flik för SOL/LSS-utredningen, synlig endast för de roller som har med den att göra.
Acceptanskriterier- Enhetschefen ser den aldrig
- Tänds när ärendet är rapporterat som missförhållande eller eskalerats dit
Källa: Confluence sida 3 & 7
-
LEX-02 Tilldelning av LEX-utredare LEX-ansvarig fördelar ärendet till en utredare. Grundregeln är att utredaren får ärendet tilldelat, inte plockar det själv.
Acceptanskriterier- I VoF gör LEX-ansvarig tilldelningen, i IAF verksamhetschefen
- Utredaren ser hela förvaltningens ärenden men blir handläggare först vid tilldelning
Källa: Confluence sida 2 & 3
-
LEX-03 Typ av händelse Utredaren markerar vilken eller vilka typer av händelse avvikelsen rör — kränkning, brister i omsorg, ekonomiska oegentligheter, bemötande eller rättssäkerhet.
Acceptanskriterier- Flerval — en händelse kan röra flera typer
- Fem alternativ enligt Confluence sida 5
Källa: Confluence sida 5
-
LEX-04 Orsaksområden och bakomliggande orsak Utredaren anger vilka orsaksområden avvikelsen berör och vad som är den primära bakomliggande orsaken.
Acceptanskriterier- Samma listor som i HSL-utredningen (se KAT-08)
- Flerval för orsaksområden, primär orsak anges separat
Källa: Confluence sida 5
-
LEX-05 Utredarens förslag till beslut om grad Utredaren föreslår vilken grad av missförhållande som föreligger, på den femgradiga skalan.
Acceptanskriterier- Förslaget är utredarens, beslutet är LEX-ansvarigs — två skilda värden
- Förslaget ska framgå tydligt vid sidan av beslutet, inte ersättas av det
Källa: Confluence sida 2 & 5
-
LEX-06 Utredarens förslag på åtgärder Sju åtgärdstyper: översyn av rutin, utbildningsinsats, kompetensutveckling, justering av bemanning, teknisk åtgärd, uppföljningssamtal och övrig åtgärd.
Acceptanskriterier- Åtgärderna riktas till den chef som ansvarar för platsen
- Samma sjulista som MAS/MAR använder
- Beskrivning och mål är obligatoriska även här (se ATG-02)
Källa: Confluence sida 5
-
LEX-07 Utredningsunderlag som PDF på ärendet När utredningen är klar dokumenteras den och beslutsunderlaget som en PDF som hänger på ärendet.
Acceptanskriterier- PDF:en är en bilaga på ärendet, inte en nedladdning som försvinner
- Ska vara läsbar för de roller som har åtkomst till LEX-fliken
Källa: Confluence sida 2
-
LEX-08 LEX-ansvarigs beslut om allvarlighetsgrad Ärendet går tillbaka till LEX-ansvarig, som fattar det formella beslutet om hur allvarligt missförhållandet är.
Acceptanskriterier- Beslutet grundas på utredarens förslag och den initiala rapporten
- Lagras som ett eget värde, skilt från beslutet om åtgärderna
- I prototypen är beslutsvärdet bara testdata — det ska kopplas till det verkliga beslutsflödet
Källa: Confluence sida 2 & 3 · prototypspec §11
-
LEX-09 Beslut om IVO-anmälan LEX-ansvarig har mandat att upprätta en IVO-anmälan när missförhållandet bedöms vara av allvarlig karaktär.
Acceptanskriterier- De två högsta graderna på skalan innebär anmälan (se KAT-09)
- Beslutet kan fattas redan i den initiala bedömningen (se FLO-08)
- MAS/MAR har eget IVO-mandat inom HSL (se HSL-06)
Källa: Confluence sida 2 & 3
-
LEX-10 Återlämning till enhetschefen När beslutet är fattat går ärendet tillbaka till enhetschefen, i dialog — inte som en tyst överlämning.
Acceptanskriterier- Antingen LEX-utredaren eller LEX-ansvarig gör återlämningen
- Chefen ska sedan hantera utredarens åtgärdsförslag (se ATG-05)
- De accepterade förslagen ska följa med till uppföljningen — en känd fallgrop i prototypen var att de inte gjorde det
Källa: Confluence sida 2 · prototypspec §8 regel 1
-
HSL-01 Trigger vid HSL-riskvärde 4 eller högre När en avvikelse har HSL-lagrum och riskvärde minst 4 aviseras MAS/MAR och HSL-utredningen aktiveras.
Acceptanskriterier- Båda villkoren måste vara uppfyllda: HSL-lagrum och riskvärde ≥ 4
- Aviseringen är obligatorisk, inte en påminnelse (se NOT-02)
- Utlöses även om riskvärdet ändras i efterhand
Källa: Confluence sida 2 & 7
-
HSL-02 Fliken Utredning HSL, läsbar för alla MAS/MAR arbetar i fliken, men den är synlig i läsläge för alla roller som har ärendet — inklusive enhetschefen.
Acceptanskriterier- Enhetschef och verksamhetschef ser HSL-utredningen men inte SOL/LSS-utredningen
- Endast MAS/MAR kan redigera innehållet
Medveten asymmetri. HSL-utredningen är öppen, SOL/LSS-utredningen är sluten. Blanda inte samman de två flikarnas behörighetsregler.Källa: Confluence sida 2 & 3
-
HSL-03 Händelseanalys MAS/MAR:s utredning kallas även händelseanalys och följer inte enhetschefens tidplan.
Acceptanskriterier- Utredningen blir ofta klar efter att chefen är färdig med sina delar
- Ärendet kan inte avslutas innan den är klar (se FLO-10)
Källa: Confluence sida 2
-
HSL-04 Identifierade och bakomliggande orsaker MAS/MAR anger vilka orsaker till händelsen som identifierats, och vad som ligger bakom.
Acceptanskriterier- Samma två listor som i SOL/LSS-utredningen (se KAT-08)
- Flerval i båda
Källa: Confluence sida 5
-
HSL-05 MAS/MAR:s åtgärdsförslag Samma sju åtgärdstyper som LEX-utredaren har. Förslagen går till enhetschefen för hantering.
Acceptanskriterier- Chefen accepterar, förkastar eller begär omarbetning (se ATG-05)
- Accepterade förslag blir del av handlingsplanen
- Ärendet kan inte avslutas förrän förslagen är hanterade
Källa: Confluence sida 2 & 5
-
HSL-06 MAS/MAR:s IVO-mandat MAS/MAR har eget mandat att anmäla ärendet till IVO inom sitt ansvarsområde.
Acceptanskriterier- Oberoende av LEX-ansvarigs mandat inom SOL/LSS
- Noteras på ärendet, anmälan upprättas utanför Draken (se INT-07)
Källa: Confluence sida 2
-
HSL-07 Verksamhetschefens obligatoriska kommentar Efter utredningen ska MAS/MAR ha dialog med verksamhetschefen, som måste skriva sina kommentarer på rapporten.
Acceptanskriterier- Ett avgränsat område i HSL-fliken är avsett för verksamhetschefens text
- Kommentaren är ett krav, inte en möjlighet
Källa: Confluence sida 2 & 3
-
HSL-08 Samtidig redigering av två personer MAS/MAR och enhetschefen kan arbeta i samma ärende samtidigt. Systemet måste tåla det utan att skriva över.
Acceptanskriterier- MAS/MAR är inte handläggare — ärendet har fortfarande enhetschefen som handläggare
- Samtidiga ändringar i skilda delar av ärendet får inte gå förlorade
Detta är en konkret teknisk risk. Två parallella redigerare i samma ärende är den enda platsen i hela flödet där samtidighet är designad, inte undantag.Källa: Confluence sida 2 & 3
-
HSL-09 MAS/MAR kan aldrig avsluta ett ärende Även när alla villkor för avslut är uppfyllda är knappen otillgänglig för MAS/MAR.
Acceptanskriterier- I uppföljningsfasen visas knappen inaktiverad med en förklaring om varför
- I övriga faser visas den inte alls
Regel som inte får brytas. Att förklara varför knappen är låst är poängen — en tyst inaktiverad knapp läses som en bugg.Källa: Confluence sida 3 · prototypspec §8 regel 2
-
HSL-10 Prenumerera på ärende Eftersom MAS/MAR inte är handläggare behöver de ett annat sätt att filtrera fram de ärenden de faktiskt arbetar med.
Acceptanskriterier- Fungerar som grund för filtret "Mina ärenden" för MAS/MAR (se BEH-09)
- Knyter ihop behörighet och notiser — samma mekanism används för aviseringar
Källa: Confluence sida 7
-
ATG-01 Åtgärder som strukturerad data på ärendet En samling åtgärder lagras på ärendet med definierad struktur, inte som fritext.
Acceptanskriterier- Föreslagen lösning: JSON med tillhörande JSON-schema på ärendet
- Färdtjänstens insatser i PartyAssets finns som förlaga för samma mönster
- Per åtgärd lagras typ, status, datum, beskrivning, mål, effekt och motivering
Källa: Confluence sida 4 · prototypspec §6
-
ATG-02 Beskrivning och mål är obligatoriska Ingen åtgärd kan sparas utan både en beskrivning av vad som ska göras och vad målet med den är — oavsett roll och formulär.
Acceptanskriterier- Gäller samtliga ställen där en åtgärd kan skapas eller redigeras — i prototypen var det sex olika formulär
- Fälten markeras som obligatoriska i gränssnittet
- Sparaknappen är inte tillgänglig förrän båda är ifyllda
Regel som inte får brytas. Kravet gäller alla formulär, inte de flesta. Missas ett enda uppstår åtgärder utan mål — och då går effekten inte att följa upp.Källa: prototypspec §8 regel 8
-
ATG-03 Åtgärdsstatus och datum En åtgärd är planerad eller genomförd, med datum för när den påbörjades och slutfördes.
Acceptanskriterier- Endast två statuslägen — inga mellansteg
- Påbörjandedatum är filtrerbart i verksamhetsuppföljningen
- Vem som lagt till åtgärden framgår
Källa: prototypspec §6 & §9
-
ATG-04 Hantera förslag: acceptera, förkasta eller omarbeta Enhetschefen tar ställning till varje åtgärdsförslag från LEX-utredare och MAS/MAR.
Acceptanskriterier- Tre utfall per förslag: accepteras, accepteras inte, eller ska omarbetas
- Accepterade förslag följer med till handlingsplanen och till uppföljningen
- Ärendet kan inte avslutas med ohanterade förslag kvar
Källa: Confluence sida 2 & 3 · prototypspec §8
-
ATG-05 Handlingsplanen Enhetschefen sätter ihop handlingsplanen av accepterade förslag — sina egna, MAS/MAR:s och LEX-utredarens.
Acceptanskriterier- Planen samlar åtgärder från tre olika källor och visar varifrån varje åtgärd kommer
- Chefen kan lägga till nya åtgärder även i uppföljningsfasen
- Chefen ansvarar för att planen genomförs
Källa: Confluence sida 2 & 3
-
ATG-06 Dokumentera effekten av genomförda åtgärder För varje genomförd åtgärd anges om den fick önskad effekt, med en motivering.
Acceptanskriterier- Ja eller nej, plus motivering i fritext
- Efterfrågas endast för genomförda åtgärder
- Är underlaget för uppföljningens analys av vilka åtgärdstyper som faktiskt fungerar
Varför den här raden finns: "svårt att bedriva verksamhetsutveckling för att minska antalet missförhållanden" är den sjunde bristen med Flexite. Utan ATG-06 finns ingen data om vad som hjälper.Källa: Confluence sida 3 · prototypspec §6
-
ATG-07 Redigera befintlig åtgärd Åtgärder går att ändra i efterhand, med vissa fält låsta beroende på var i flödet ärendet står.
Acceptanskriterier- Samma redigeringsvy återanvänds i utredning, beslut och uppföljning
- I uppföljningsfasen är startdatumet låst
- Obligatoriska fält gäller även vid redigering (se ATG-02)
Källa: prototypspec §8 regel 8
-
ATG-08 Åtgärdsärende som egen ärendetyp Åtgärder kan behöva följas som egna ärenden, skilt från avvikelsen som utlöste dem.
Acceptanskriterier- Ärendetypen
ACTIONSfinns definierad men användningen är inte utredd - Öppen fråga: när ska en åtgärd bli ett eget ärende i stället för en post på avvikelsen?
Källa: Confluence sida 4
- Ärendetypen
-
UPF-01 Översiktsvy anpassad efter roll Samma vy, olika omfång: enhet för enhetschefen, enheter för verksamhetschefen, hela verksamhetsområdet för de tvärfunktionella rollerna.
Acceptanskriterier- Rubriken följer rollens omfång, inte en fast text
- Synlig för alla roller, med olika mängd data
- Enhetsfiltret visas även för enhetschefer som ansvarar för flera enheter
Källa: prototypspec §9 · Confluence sida 1
-
UPF-02 Lägesbild med nyckeltal Fem tal överst: avvikelser, missförhållanden, IVO-anmälda ärenden, pågående åtgärder och ej påbörjade ärenden.
Acceptanskriterier- Räknas på de senaste tolv månaderna, med perioden angiven i text
- Öppen fråga från prototypen: ska talen följa filterraden eller alltid visa hela omfånget?
Källa: prototypspec §9.1 & §11
-
UPF-03 Varning för ej påbörjade ärenden Ärenden som legat i inkommet läge i mer än trettio dagar lyfts fram med varningsfärg — det betyder att chefen ligger efter.
Acceptanskriterier- Varningsvarianten visas endast när antalet är större än noll
- Bygger på registreringsdatum, men blir bättre med fas-tidsstämplar (se MOD-08)
Varför den här raden finns: "ärenden blir liggande" är en av de sju bristerna. UPF-03 gör det synligt i stället för att bara hoppas att det inte händer.Källa: prototypspec §9.1
-
UPF-04 Ärendefilter Filtrering på rapporttyp, enhet, tidsperiod, avvikelsetyp, underkategori, orsak, lagrum, IVO-anmälan och de två riskvärdena.
Acceptanskriterier- Filtren kombineras med OCH; flervalsfilter använder ELLER internt
- Riskvärdena filtreras i band: låg 1–3, måttlig 4–6, hög 7–9
- Enhetsfiltret visas bara för roller med mer än en enhet i sitt omfång
- Öppen fråga: när båda riskfiltren är satta — OCH eller ELLER?
Källa: prototypspec §9.1 & §11
-
UPF-05 Sorterbar ärendetabell Enhet, typ, orsak, registreringsdatum, båda riskvärdena, IVO-anmälan, beslutad grad av missförhållande och antal åtgärder.
Acceptanskriterier- Alla kolumner sorterbara
- Allvarligt missförhållande markeras särskilt
- Varje rad leder till ärendet
Källa: prototypspec §9.1
-
UPF-06 Åtgärdsvy med samma filter En egen vy över åtgärder, filtrerad via sina ärenden plus åtgärdsspecifika filter för typ, status och effekt.
Acceptanskriterier- Ärendefiltren delas mellan de två vyerna — ett filter satt i den ena gäller i den andra
- Tidsperioden filtrerar här på påbörjandedatum, inte registreringsdatum
- Raderna går att fälla ut för beskrivning, mål, effekt och motivering
Källa: prototypspec §9.1
-
UPF-07 Ärendeinsikter, regelbaserade Automatiska signaler ur statistiken: underrapportering per enhet, flera missförhållanden, hög andel högriskärenden, dominerande avvikelsetyp, åtgärder utan effekt.
Acceptanskriterier- Bygger enbart på statistik — analyserar aldrig fritext
- Ärver enhetsfilter och tidsperiod från ärendevyn
- Trösklarna är demovärden i prototypen och måste kalibreras mot verklig data
Löftet är avgörande: insikterna rör aldrig fritext. Det är vad som skiljer dem från AI-analysen i UPF-08, och det är därför de kan visas utan datarisk.Källa: prototypspec §9.0 & §11
-
UPF-08 AI-analys av åtgärdstexter Analys av vad som skiljer åtgärder som gav effekt från dem som inte gjorde det, baserat på de skrivna beskrivningarna och motiveringarna.
Acceptanskriterier- Kräver minst ett aktivt filter och har en övre gräns för urvalets storlek
- Resultatet gråas ut om filtren ändras efter analysen
- Följdfrågor besvaras alltid utifrån det analyserade urvalet, inte aktuella filter
- I prototypen är detta en deterministisk attrapp — det verkliga anropet återstår
Behöver ett eget beslut om datahantering. Här skickas fritext som kan innehålla känsliga uppgifter till en språkmodell. Gränsen mot UPF-07 är medveten och måste hållas.Källa: prototypspec §9.1
-
UPF-09 PDF-export av urval Det filtrerade och sorterade urvalet går att exportera, med rubrik, roll, filtervillkor och tidsstämpel.
Acceptanskriterier- Exporten återger exakt de kolumner och den ordning som visas i vyn
- Filtervillkoren skrivs ut, så att ett utskrivet underlag går att tolka i efterhand
- Finns för både ärenden och åtgärder
Källa: prototypspec §11
-
UPF-10 Detaljvy per enhet En samlad bild för en enskild enhet: nyckeltal, fördelning per avvikelsetyp, orsak, lagrum och riskpoäng, plus enhetens ärenden.
Acceptanskriterier- Riskpoäng redovisas uppdelat HSL mot SOL/LSS
- Öppen fråga: hur ska vyn nås? I prototypen finns den byggd men utan ingång från översikten
Källa: prototypspec §9.2 & §11
-
UPF-11 Aggregering mot sparad data Statistiken ska räknas på det som faktiskt sparats i ärendena, inte på testdata eller separata fält.
Acceptanskriterier- I prototypen läser aggregeringen statiska testfält och inte det som matats in i formulären — en medveten förenkling som måste bort
- Kräver att MOD-07 finns på plats
Källa: prototypspec §6 & §11
-
UPF-12 Trender över tid Tidsserier, säsongsvariation, periodjämförelse och handläggningstider. Uttalat uppskjutet.
Acceptanskriterier- Kräver grafiska komponenter som ännu inte finns
- Kräver fas-tidsstämplar för allt som rör handläggningstid (se MOD-08)
- Datumfiltret är förberedelsen — inte funktionen
Källa: prototypspec §11
-
NOT-01 Avisering vid tilldelning När ett ärende tilldelas en roll eller person skickas ett mail. Gäller särskilt den automatiska tilldelningen efter sju dagar.
Acceptanskriterier- Utlöses av både manuell och automatisk tilldelning
- Mottagaren skiljer sig mellan förvaltningarna (se BEH-10)
Källa: Confluence sida 2
-
NOT-02 Avisering till MAS/MAR vid riskvärde 4 eller högre MAS/MAR måste få veta att ett ärende kräver deras händelseanalys — de bevakar inte listan själva.
Acceptanskriterier- Aviseringen är obligatorisk enligt processbeskrivningen
- Utlöses även om riskvärdet höjs i efterhand
Källa: Confluence sida 2
-
NOT-03 Avisering om stillastående ärenden Ligger en avvikelse kvar i samma fas för länge går en avisering till verksamhetschefen.
Acceptanskriterier- Kräver fas-tidsstämplar (se MOD-08)
- Öppen fråga: hur många dagar? Gränsen är inte bestämd i underlaget
- Går till verksamhetschefen, inte till enhetschefen som redan ligger efter
Källa: Confluence sida 7
-
NOT-04 Prenumeration som notisgrund Den som prenumererar på ett ärende får aviseringar om det, utan att vara handläggare.
Acceptanskriterier- Samma mekanism som ger MAS/MAR sitt "Mina ärenden" (se HSL-10)
- Går att slå av och på per ärende
Källa: Confluence sida 7
-
NOT-05 Avisering till rapportören Rapportören får veta när något händer i ärendet — vid komplettering, vid återkoppling och vid avslut.
Acceptanskriterier- Aviseringen leder till Mina sidor i Katla, inte in i Draken
- Innehåller inga uppgifter om utredningen — bara att det finns något att läsa
Kärnan i hypotesen. Utan NOT-05 upplever rapportören ingen återkoppling, oavsett hur bra Mina sidor är byggda — ingen loggar in för att kontrollera.Källa: Confluence sida 1 & 3
-
INT-01 SupportManagement som ärendelager Webbappen Draken Avvikelser anropar mikrotjänsten SupportManagement, som håller ärendena.
Acceptanskriterier- Skilda namespaces för VoF och IAF
- Utökningar av datamodellen behöver kartläggas tidigt (se MOD-07)
Källa: Confluence sida 4
-
INT-02 Employee API Ger förvaltning, enhet, chefskap och organisationsträd för en anställd, plus vem som är någons chef.
Acceptanskriterier- Organisationsträdets nivåer används för att härleda förvaltning, verksamhet, enhet och plats
- Chefskap läses som en egen egenskap (se BEH-12)
Källa: Confluence sida 4
-
INT-03 MDViewer API för platser Håller de platser som går att välja vid registrering, hämtade ur organisationsträdet.
Acceptanskriterier- Anropas som
GET /{orgId}/orgtree - Enligt underlaget täcker detta det mesta av behovet — ingen ny mikrotjänst för platser krävs
- Öppen fråga: är platsinformationen jämförbar mellan VoF och IAF?
Källa: Confluence sida 4
- Anropas som
-
INT-04 DataWarehouseReader för chef och enhet Kopplar samman vilken chef som ansvarar för vilken enhet, och vice versa.
Acceptanskriterier- Underliggande data kommer från datalagret, med ursprung i personalsystemet
- Avgör vem som blir intressent och handläggare vid registrering (se FLO-05)
Källa: Confluence sida 4
-
INT-05 ActiveDirectory API för grupptillhörighet Hämtar vilka AD-grupper en användare tillhör, om behörighetslösningen kräver det.
Acceptanskriterier- Behovet beror på vilken behörighetsmodell som väljs (se BEH-04 och BEH-05)
- Ett användarId från frontend betraktas som säkert i version 1 — signering är uttalat utanför omfattningen
Källa: Confluence sida 4
-
INT-06 IAF:s avvikande organisationsträd Enhetsnivån ligger inte på samma plats i IAF:s träd som i VoF:s. Det slår rakt in i behörighetsfiltreringen.
Acceptanskriterier- Frågan är ställd i underlaget men inte besvarad
- Behörighetsmodellen får inte anta en fast nivå för enhet
Obesvarad fråga med hög påverkan. Antas fel nivå ser fel personer fel ärenden. Bör klaras ut innan behörighetsfiltreringen byggs.Källa: Confluence sida 4
-
INT-07 IVO-anmälan sker utanför Draken Själva anmälan upprättas i annan ordning, men noteras på ärendet så att den går att följa upp.
Acceptanskriterier- Draken bygger ingen integration mot IVO
- Ärendet ska däremot bära att anmälan gjorts, och av vem
- IVO:s eventuella återkoppling är en känd framtida fråga
Källa: Confluence sida 4 · prototypspec §11
-
INT-08 Återanvändbar för andra scenarion Behörighetslösningen ska gå att tillämpa på andra fall än avvikelser, exempelvis MiniDraken.
Acceptanskriterier- Lösningen får inte bygga in antaganden som bara gäller avvikelsehantering
- Framtida utökning: begränsa vissa delar av ett ärende till viss behörighetsnivå — uttalat utanför omfattningen för version 1
Källa: Confluence sida 4