Registreringsformuläret finns i testmiljön
Rapportörens formulär går att prova under sprinten: draken-test.sundsvall.se. Inloggningsuppgifter finns i teamskanalen. Miljön nås inifrån kommunens nät, och teamet skriver i kanalen när den uppdateras och kortvarigt ligger nere.
Skriv inga verkliga uppgifter. Det är en testmiljö — inga namn, personnummer eller beskrivningar av faktiska händelser, varken om brukare eller personal.
Det som visas är halvfärdigt med flit. Hittar du något som är fel, otydligt eller saknas, säg det på standupen eller i teamskanalen — hellre samma dag än nästa vecka.
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.
Sprintarna ska pröva den kedjan i den lösning som ska driftsättas, inte i en demo. Håller något inte vill vi veta det tidigt — men riktningen är bestämd: det vi bygger ska i produktion.
Teknisk förberedelse — redan gjord
Under en dryg vecka, 10–17 augusti, kördes en teknisk förberedelsesprint. Syftet var enkelt: de klurigaste tekniska frågorna ska inte äta upp tiden när vi sitter tillsammans med verksamheten. Tre av dem är utredda och till stor del byggda.
Behörighet löses av AD-grupper plus ett lokalt register
Åtkomst översätts från AD-grupper till interna access-grupper. Under sprinten tillkom ett register över enskilda användares behörigheter, med sökning som fortsätter lokalt när personen inte finns i Active Directory. Underlaget beskrev synktjänst och administrationsvy som två alternativ — lösningen kombinerar dem.
Utredningsformulären styrs av scheman, inte av kod
Utredningsfälten definieras som versionerade scheman i stället för att byggas in i gränssnittet. Det avgör var taxonomin ska bo: i schemat. Nya fält och ändrade kategorier blir därmed en konfigurationsändring, inte ett utvecklingsjobb.
Arbetsplatserna finns inte i organisationsträdet
Platsvalet kan inte hämtas ur organisationsträdet, eftersom arbetsplatserna inte finns där. De underhålls i stället som en egen struktur, med samma logik i rapportörens e-tjänst och i handläggarens vy.
Vi kan börja i verksamhetens frågor, inte i infrastruktur
Behörighetsmodellen, formulärmotorn och platsvalet är på plats i grunden. Sprinten kan därför börja i det som faktiskt behöver verksamhetens svar — vem ser vad, vilka fält behövs, hur ska flödet kännas.
En sak följer däremot med som en verksamhetsfråga snarare än en teknisk: någon måste äga och underhålla platsstrukturen. Den uppdaterar sig inte själv.
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 i korta cykler och visar tidigt — men vi bygger det som ska driftsättas. Målet är en lösning i produktion, inte en demo.
Tre faser per sprint
Teknisk förberedelsesprint: behörighetsmodell, schemadrivna utredningsformulär och platsval utreddes och byggdes i grunden, och sprintbasen sattes upp. Det som återstår av Fas 0 är verksamhetens del — vilka som deltar och hur involveringen ska se ut.
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.
Efter sprint 1 vägs resultatet mot hypotesen och riktningen justeras. Efter sprint 2 är målet en produktionsfärdig lösning, och utvärderingen handlar då om vad som återstår före driftsättning. Lärdomarna dokumenteras och 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.
Målet är att vara produktionsfärdiga när sprint 2 är slut. Det vi bygger är alltså inte en prototyp som ska göras om efteråt — det är lösningen, byggd i skarp miljö från början.
- 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
- Produktionsfärdig lösning vid sprintens slut
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.
Parallellt med testningen sker finslipning av UI och UX. Det som fungerar men skaver — utformning, flöden, ordval — jämnas ut medan verksamheten provar. Det är medvetet lagt här: sådant arbete blir bättre när det finns riktig användning att utgå från, och det tar tid från annat om det görs mitt i en sprint.
Ny funktionalitet påbörjas inte under uppehållet. Det som inte hanns med i sprint 1 går tillbaka in i prioriteringen för sprint 2 — det byggs inte i mellanrummet. Det som ryms här är testning, återkoppling och finslipning av det som redan finns.
För dig som deltagare betyder det också att det du byggt mycket väl kan behöva göras om när verksamheten sagt sitt. Det är meningen.
Standupen håller ihop sprinten
Varje dag 08.15, ungefär en halvtimme. 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.
Hur beslut fattas under sprinten
En sprint utan kravdokument står och faller med att beslut går snabbt. Men alla beslut är inte teamets att fatta, och att blanda ihop dem är ett säkert sätt att antingen tappa tempo eller besluta något man inte har mandat för. Tre nivåer:
I rummet, samma dag
Namn på fält, ordning i ett formulär, hur en vy ska se ut, vilken teknisk lösning som väljs. Den som sitter närmast frågan avgör, direkt. Ingen väntar på nästa möte och ingen behöver stämma av uppåt. UI/UX är med i teamet och äger frågor om utformning och flöde i gränssnittet, och arkitekten är beslutsför inom arkitektur — även systemgripande tekniska val avgörs alltså i rummet.
På standupen, med verksamhetens mandat
Processregler och det som styr hur ärenden faktiskt hanteras: vem som ska se vad, vad ett fält betyder i praktiken, när ett ärende får gå vidare. Här räcker det inte att lösningen fungerar tekniskt — verksamheten måste stå bakom den. Lyft frågan på standupen samma dag som den uppstår.
Juridiken, som kan behöva eskaleras
Lagtolkning kring missförhållanden och IVO, och hantering av personuppgifter. Det här är inte teamets beslut, hur uppenbart svaret än verkar, och det finns ingen i rummet som kan avgöra det. Fatta inget tillfälligt beslut och bygg vidare på det — flagga frågan, dokumentera vilket antagande du arbetar utifrån, och gå runt den tills den är besvarad.
Att kunna stoppa ett beslut är inte samma sak som att fatta det
Sprintledaren kan stoppa ett beslut på alla tre nivåerna — typiskt när det drar iväg i omfattning, spretar från hypotesen eller binder oss på ett sätt vi inte vill. Vetot är en bromsklots, inte en genväg: sprintledaren tar inte över frågan, den går tillbaka till den som äger den.
Så vet ni vem frågan ska till
- Sprintledare — håller ihop dagarna, har veto
- Arkitekt — beslutsför inom arkitektur
- UI/UX — utformning och flöde i gränssnittet
- Utvecklare — bygger, och visar på standupen
- Enhetschefer
- LEX-ansvarig och LEX-utredare
- MAS och MAR
- Controller, systemförvaltare, verksamhetsutvecklare
Två ställen, beroende på vad beslutet rör
Ändrar beslutet en funktion skrivs det in på berörd rad i funktionslistan. Då står beslutet där kravet står, och nästa person som läser raden ser det direkt.
Rör det arbetssätt, prioritering eller dagens läge hamnar det i sprintloggen.
Tre beslut ligger redan i funktionslistan från förarbetet: att ursprungstypen styr och aldrig ändras, att verksamhetens statusmodell gäller, och vem som kategoriserar ett eskalerat ärende. Ett exempel på nivå tre ligger också där — UPF-08 om att skicka fritext till en språkmodell. Den frågan är flaggad, inte avgjord.
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
Vi prövar antagandena tidigt — i den lösning som ska driftsättas.
Löpande anpassning
Processen utvecklas under sprintens gång.
Målet: produktionsfärdig efter sprint 2
Målet är uttalat. När sprint 2 är slut ska lösningen vara produktionsfärdig. Det här är inte ett prototypbygge som sedan ska värderas — det är den lösning som ska driftsättas, och den byggs i skarp miljö från början.
- Verksamheten testar det som byggts, på riktigt
- Återkopplingen styr innehållet i sprint 2
- Riktningen justeras — målet ändras inte
- Produktionsfärdig lösning
- Driftsättning och uppskalning
- Det som återstår är känt och avgränsat
Att arbeta hypotesdrivet betyder att vi lyfter det som inte håller tidigt, i stället för att upptäcka det sent. Det ändrar hur vi arbetar — inte vad vi siktar på.
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.
Snabbt betyder däremot inte ensamt i alla frågor. Vilka beslut du tar själv, vilka som hör till standupen och vilka som måste eskaleras står under Hur beslut fattas i fliken Sprinten.
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–40 är till för att verksamheten ska hinna testa och ge återkoppling, och för att UI och UX ska finslipas mot det som faktiskt används. Ny funktionalitet påbörjas inte här. Det du inte hann med i sprint 1 tas upp i prioriteringen för sprint 2 — uppehållet är ingen buffert och ingen plats att parkera saker på.
Det perfekta är det godas fiende. Men det vi bygger ska driftsättas — vi håller tempo genom att prioritera hårt, inte genom att sänka kvaliteten.
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.
Demo-prototypen räknas inte som levererad. Den visar riktningen och är förankrad med verksamheten, men den saknar backend och nollställs vid omladdning. Lösningen byggs i skarp miljö från början, och därför står i princip allt som ogjort vid sprintstart. Undantaget är registreringsformuläret, som i huvudsak finns på plats.
Listan är den kravbild som ska vara uppfylld för att lösningen ska vara produktionsfärdig efter sprint 2.
Räknaren nedan visar läget, och den räknas fram ur raderna själva — den blir aldrig gammal. Klart betyder verifierat med tester och CI, inte driftsatt. Det som är mergat till main ligger inte i skarp miljö, och resten ligger på sprintbranch. Rader som rörts under sprinten står som pågår, och flyttas i takt med att sprintloggen fylls på.
En rad står som utanför sprintarna: AI-tolkningen av fritext, som lämnades utanför på uppstartsmötet och därför inte räknas in i det som ska hinnas.
-
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.Beslutad regel: rapportören kommer först i formuläret, därefter typ av rapport. Kommunens e-tjänsteplattform har den ordningen i över tvåhundra e-tjänster, och ett kommungemensamt ärendehanteringssystem förutsätter samma flöde överallt. Beslutat på standupen 2 september 2026.Beslutad regel: hjälptexterna under rubrikerna står kvar och visas direkt, inte först när ett val gjorts. Verksamheten begärde att de skulle tas bort eller fällas ut vid klick, UX höll fast vid att de ska synas av tillgänglighetsskäl, och verksamheten gav med sig. Det som avgjorde var jämförbarheten: den som är osäker måste kunna väga avvikelse mot missförhållande mot varandra, och klickar man fram ett i taget syns bara det ena. Rubrikbyten görs, hjälptexterna följer inte med. Upplägget omprövas när formuläret testas med riktiga användare — blir bilden för rörig går texterna att plocka bort. Beslutat vid avstämningen 4 september 2026.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
Beslutad regel: brukaren identifieras med personnummer, och uppgifterna hämtas via Meta ur folkbokföringen. Skrivs personen in manuellt med bara namn saknas kopplingen till tidigare avvikelser till dess att enhetschefen kompletterat med personnummer — rapportören kan inte göra det själv. Frågan om vilken katalog som får sökas avgörs av informationssäkerhetsklassningen. Beslutat på standupen 2 september 2026.Beslutad regel: fritextdelen heter Händelsen, inte Beskrivning av händelse, och rapportörens förslagsfält heter Förslag på förbättringar. Där formuläret talar om vad som registreras används rapporten, inte händelsen. Den som berörs kan anges som grupp eller hela verksamheten, inte bara som enskild part. Rubriken för omedelbara åtgärder är inte avgjord. Beslutat vid verksamhetens test av rapporteringsformuläret 1 september 2026.Beslutad regel: fältet för omedelbart vidtagna åtgärder är frivilligt, inte obligatoriskt. Fältet står kvar. Det hade blivit tvingande utan att beslutet fattats, och alla avvikelser går inte att knyta till en akut åtgärd i stunden — längre förlopp där kännedomen kommer i efterhand går varken att datera eller peka på, och ett tvingande fält ger då en punkt i rutan i stället för innehåll. Att skriva avvikelsen är i många fall åtgärden. Invändningen att det inom hälso- och sjukvård är viktigt att beskriva vad som gjorts akut kvarstår; enhetschefen fyller i sina omedelbara åtgärder i nästa steg. Ordvalet i rubriken är fortfarande inte avgjort. Beslutat vid avstämningen 4 september 2026.Beslutad regel: identifieringen byggs på dagens lösning under sprintarna. Nya integrationer mot Lifecare görs först när det projektet är på plats och integrationerna är implementerade — de ryms inte här. Beslutat vid verksamhetens test av rapporteringsformuläret 1 september 2026.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 pekas ut av rapportören bland de platser som hör till förvaltningen — enhet, eller avdelning där enheten har avdelningar. Platsvalet på plats i Katla: sökning i label-strukturen, utan förval
Acceptanskriterier- Rapportören söker fram platsen i label-strukturen
- Inget förval — platsen väljs alltid aktivt
- Rapportörens anställning fyller i organisationen; enhetschefen härleds ur platsen och inte ur anställningen (se FLO-05)
- Rapportörens förvaltning avgränsar vilka platser som visas
- Platsen avgör vilken enhetschef ärendet tilldelas
Beslutad regel: platsen förväljs inte. En avvikelse ska hanteras på den enhet där den inträffade, inte hos rapportörens egen chef — ett förval som blir fel fördröjer hanteringen. Beslutat på standupen 1 september 2026.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 Rapporterar man åt en kollega blir kollegan rapportör på ärendet — den som fyllt i uppgifterna står som den som lämnat in dem. Redigering av partsuppgifter borttagen i Katla; ägarskapet enligt beslutet är inte byggt
Acceptanskriterier- Kollegan blir rapportör och är den som ser ärendet på Mina sidor
- Notiser och begärd komplettering går till kollegan, inte till den som fyllde i rapporten
- Partsrollerna i ärendelagret ska spegla det — hur den som fyllde i rapporten lagras är inte avgjort
Beslutad regel: kontaktuppgifter går inte att redigera i formuläret, varken på rapportören eller på kollegan. Systemet visar det personaldatan ger. Saknas e-post eller telefon går kontakten via enhetschefen, som i dag — priset är att rapportören inte kan aviseras om en begärd komplettering. Beslutat på standupen 2 september 2026.Beslutad regel: rapporterar man åt en kollega blir kollegan rapportör, inte den som satt vid tangentbordet. Det är den som identifierat avvikelsen som ska stå för den, och det är dit notiser och begärd komplettering går — och den som kan logga in och se vad som lämnats in. Beslutat på standupen 3 september 2026.Beslutad regel: vid manuell registrering heter åtgärden lägg till rapportör, inte lägg till person, och fältet för telefonnummer förtydligas med (ej privat). Texten som visas när rapporteringen görs åt en kollega står kvar. Beslutat vid verksamhetens test av rapporteringsformuläret 1 september 2026.Källa: Confluence sida 3
-
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. Överblicken byggd i Katla: egna rapporter, inskickade och avslutade
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. Rapportörens åtkomst uttrycks som egen behörighetsnivå · IT-testad
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. Meddelanden via Katla bär bilagor, och skickas först när ärendet lämnat första fasen
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
-
RAP-11 Anställningsform på rapportören och kollegan Anställningsformen — tillsvidare eller vikariat — följer med rapporten, för rapportören och för den kollega hen rapporterar åt. Härleds automatiskt i backend — valet i formuläret är borttaget
Acceptanskriterier- Formen härleds ur anställningen i stället för att väljas i formuläret
- Gäller både rapportören och den kollega man rapporterar åt
- Värdet lagras som parameter på parten, inte som fritext
- Syftet är uppföljning: att kunna se om det är vikarier som rapporterar
Beslutad regel: anställningsformen anges av rapportören så länge den inte går att härleda. Personaldatan ger yrkestitel, inte anställningsform — att någon är vikarie framgår bara indirekt av var i organisationsträdet anställningen hänger. Teamet undersöker källan en gång till innan valet blir permanent. Beslutat på standupen 2 september 2026.Beslutad regel: anställningsformen sätts automatiskt. Uppgiften visade sig gå att härleda ur anställningen, så rapportören ska inte behöva svara på den. Detta ersätter beslutet dagen före om att formen anges i formuläret. Beslutat på standupen 3 september 2026.Källa: standupen 2 september 2026
-
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. Lagrum sorteras deterministiskt i utredningsvyn
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å. IVO- och Public 360-nummer sätts på ärendet vid anmälan
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å. Plats och kontext ligger som labels i ärendelagret — sökväg och versionsfält på plats
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. Åtgärder, fält- och resursbehörighet samt konfigurerbar validering ligger på main
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
Beslutad regel: den automatiska kopplingen mellan ärenden vilar på personnummer. En brukare som skrivits in manuellt med bara namn ger ingen koppling förrän enhetschefen kompletterat. Beslutat på standupen 2 september 2026.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. Label-bindning på plats: CATEGORY → classification.type
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. Label-bindning på plats: PROVISION-CATEGORY → classification.category
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. Kategori och lagrum bundna via labels
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. Kategoriseringskontrollen styrs av placering och label-träd, delat mellan VoF och IAF
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. SoL/LSS-utredningen kategoriserar med bara SoL/LSS-väljaren
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. Kategoriseringen per lagrumsgrupp är byggd — tillåtna kombinationer avviker från raden
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änt hål: verksamheten bad 30 augusti om kombinationen med alla tre lagrum, och utredningsschemat 1.3, publicerat i testmiljön 17 september 2026, tillåter den. Den är ingen av de sex kombinationerna raden räknar upp, och teamet har frågat om verksamheten ändrat sig. Bekräftas den ska raden få en sjunde kombination. Källa: textändringar för enhetschefssteget, 30 augusti.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. Rutinområdet har bytt namn enligt verksamheten — övriga etiketter återstår
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änt hål: verksamheten ändrade orsaksområdena 11 september till kommunikation, information · omgivning, organisation · processer, rutiner, arbetssätt, riktlinjer · teknik, utrustning, apparatur · kompetens, utbildning. Sedan 5 oktober heter rutinområdet rätt i enhetschefens och SoL/LSS-utredningen. Kvar är HSL-utredningens egen variant, och att kompetens saknas hos enhetschefen och heter olika i de andra två utredningarna. Källa: textändringar för enhetschefsvyn, 11 september.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. Versionerade JSON-scheman · kontraktstester och Playwright i CI
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. Fasmodellen styr statusar och avslut, med processknapp i sidopanelen
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. Tilldelat sätts vid överlämning och återlämning, avvaktar svar vid begärd komplettering
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. Fashanterare med placering och styling på plats
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. Ett återupptaget ärende får den aktiva fasens status
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.Beslutad regel: ett ärende som väntar på komplettering låses inte. Enhetschefen kan återuppta det när som helst, oavsett om kompletteringen har kommit. Beslutat på standupen 6 oktober 2026.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. orgId och chef sätts vid platsval inom egen anställning
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
Beslutad regel: chefen härleds via platsen, inte via rapportören. Systemet utgår från en anställd på avdelningen och frågar vem som är chef för den, och får därigenom ut enhetschefen; verksamhetschefen är chefens chef. Legitimerad personal arbetar på flera ställen, och en avvikelse ska hanteras av chefen för den enhet där den inträffade — inte av personalens egen chef. Två kända hål: vikarier saknar strukturen och måste välja plats, och den som står som enhetschef i systemet är inte alltid den faktiska. Beslutat på standupen 3 september 2026.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. Överlämning till LEX-ansvarig vid klassat missförhållande på plats
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. Ett felplacerat ärende kan flyttas till rätt enhet
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. Avslut spärras så länge en åtgärd är ohanterad — spärren för pågående HSL-utredning återstår
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. Beslut kräver LEX-ansvarig och klarmarkerad utredning, och medan LEX har ärendet är det låst för cheferna
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
Beslutad regel: enhetschefen kan inte avsluta ett missförhållande. I testet gick det, och det rättas. Beslutat vid testrundan av Lex Sarah-flödet 8 oktober 2026.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. Handläggarrollerna samlade i en katalog, med en AD-grupp per roll
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
Beslutad regel: enhetschefer registrerar inte via Katla — de skapar ärendet i handläggningsdraken. Samma mönster som de befintliga drakarna, och en förberedelse för de ärendetyper som aldrig kommer in via Katla. Att en chef rapporterar i sin egen verksamhet är inget märkligt, snarare en förutsättning; ska ärendet till verksamhetschefen tilldelas det manuellt på vanligt sätt — ingen automatik byggs. Beslutat på standupen 3 september 2026.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. VoF och IAF finns som egna drakar med delat utredningsflöde
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. AD-grupper mappas till interna access-grupper · IT-testad, mergad till main
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. Access-grupper på plats — koden på ärendet återstår
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. AccessUser med CRUD för lokalt lagrade behörigheter · ärendefiltrering på label-mönster IT-testad i backend
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
Beslutad regel: dubbla roller slås samman. Den som är både rapportör och enhetschef får inte en beskuren vy, utan ser det rollen ger. Beslutat på standupen 3 september 2026.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. Tilldelningsbara handläggare konfigureras genom AD-grupper, med uttalat fallback
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. Flikarna följer ärendets eget åtkomstsvar — dold, läsbar eller redigerbar — med e2e-tester
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. orgId och chef skrivs bara inom egen anställning
Acceptanskriterier- Hämtas via Employee API
- Används som komplement till AD-gruppen, inte i stället för den
Känt hål: den som står som enhetschef i personaldatan är inte alltid den faktiska. Härledningen är alltså ett svagare skydd än raden utgår från, och en annan väg att hitta rätt chef för en enhet behövs. Konstaterat på standupen 3 september 2026.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. Enhetschefens del härleds ur AD-grupper, med spärr även i ärendelagret
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änt hål: valet av utredningsmall har tre alternativ — SoL/LSS, HSL och SoL/LSS med HSL — men verksamheten har bara två mallar. Väljer chefen HSL fylls ingen text i. Antingen tas alternativet bort eller så får det en mall. Källa: teamschatten 5 oktober.Beslutad regel: missförhållanden får samma utredningsmall för SoL/LSS som avvikelser. Beslutat vid testrundan av Lex Sarah-flödet 8 oktober 2026.Källa: Confluence sida 2 & 3
-
UTR-02 Orsak till avvikelsen Chefen anger vilket orsaksområde avvikelsen hör till, ur den delade orsaksmodellen. Orsaksfälten schemadrivna
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. Riskberäkningen flyttad till delad modul
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. Riskberäkningen flyttad till delad modul
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. Utredningen kräver explicita val i stället för tysta standardvärden
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 Enhetschefen väljer åtgärdstyp ur en lista som verksamheten reviderade 11 september: förändring av rutin eller arbetssätt, handledning/metodstöd, utbildning/kompetensutveckling, arbetsrättslig åtgärd, teknisk eller fysisk åtgärd, information eller förtydligande, individanpassning av stöd, samverkan och övrig åtgärd med angiven typ. Går man vidare till beslut utan åtgärder måste det bekräftas
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änt hål: åtgärdstyperna ligger som inställningar i ärendelagret, inte i koden, så det är inte kontrollerat att den nya listan är inlagd. Övrig åtgärd har inget fält där typen kan anges. Polisanmälan är inte avgjord, se fråga #31. Källa: textändringar för enhetschefsvyn, 11 september.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. Utredningen delas efter ägare — den del man inte äger lyfts ur flikraden
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. Utredningsfält via schema, delat mellan VoF och IAF
Acceptanskriterier- Flerval — en händelse kan röra flera typer
- Fem alternativ enligt Confluence sida 5
Beslutad regel: lagrum sätts inte automatiskt till SoL och LSS i ett missförhållande. LEX-utredaren anger lagrum i Utredning Lex Sarah, så att statistiken kan skilja LSS från äldreomsorg. Beslutat vid testrundan av Lex Sarah-flödet 8 oktober 2026.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. Orsaksfält via schema, delat mellan VoF och IAF
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. Förslag till beslut är en egen del i utredningen enligt verksamhetens mall
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
Beslutad regel: frågan om IVO-anmälan tas bort ur utredarens förslag till beslut. Graden av missförhållande visar redan om ärendet ska anmälas, och LEX-ansvarig fattar det formella beslutet. Beslutat vid testrundan av Lex Sarah-flödet 8 oktober 2026.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. Skapa rapport sparar och bifogar en numrerad PDF; förhandsgranskning bifogar inget
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. Beslutsdokumentet för Lex Sarah på plats, med obligatorisk motivering
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. Ärendenummer för IVO och Public 360 sätts vid anmälan, och LEX-ansvarigs initiala bedömning förifyller beslutet
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. Vid återlämning tilldelas chefen för ärendets plats, ur behörighetstjänsten
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. Hög HSL-risk märks när utredningen sparas med riskvärde 4 eller mer, och märkningen ligger kvar
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. Läsa och ändra är åtskilt, och cheferna ser Händelseanalys HSL först vid hög HSL-risk
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. Samma orsaksmodell via schema som SOL/LSS-utredningen
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. HSL-beslutet om IVO-anmälan finns som eget dokument
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. Versionskontroll på ärendet och alla handläggningsdokument, åtgärden inräknad
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. MAS/MAR väljs i en egen väljare, och Mina ärenden visar deras ärenden
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. Åtgärdsmodell med CRUD, validering och migrationer · IT-testad, mergad till main
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. Fälten rymmer nu 3 000 tecken — att de är obligatoriska är inte satt i modellen
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.Att ta upp i sprinten: i backend är åtgärdstyp, användare och roll obligatoriska — men inte beskrivning och mål. Regeln finns alltså inte i datamodellen än.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. Planerad start, planerat klardatum och genomförandedatum finns — status som eget begrepp kvarstår
Acceptanskriterier- Endast två statuslägen — inga mellansteg
- Påbörjandedatum är filtrerbart i verksamhetsuppföljningen
- Vem som lagt till åtgärden framgår
Beslutad regel: startdatum på en åtgärd går inte att ändra i uppföljningen, men slutdatum gör det. Om LEX-utredarens åtgärdsförslag ska ha frivilliga datum utreds. Se fråga #44. Beslutat vid testrundan av Lex Sarah-flödet 8 oktober 2026.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. Förslag godkänns, nekas eller omarbetas med motivering, och ohanterade förslag spärrar avslut
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. Handlingsplanen kan skapas som PDF och bifogas ärendet
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. Uppföljningen frågar efter effekten, och ärendet avslutas först när åtgärderna är uppföljda
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. Uppdatering och patch IT-testade — fältlåsning beroende på fas kvarstå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. Åtgärdstypen bärs som identifierare på åtgärden, med versionshantering
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. Menyknappen och omfånget följer rollen: enhet, enheter eller verksamhetsområde
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. Fem lägeskort över periodens ärenden, med ärendena bakom varje tal
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. Lägeskortet för ärenden som stått som Ny i mer än 30 dagar blir orange
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. Filter enligt skissen i verksamhetsuppföljningen
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. Ärendetabellen i verksamhetsuppföljningen, sorterbar
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. Åtgärdsfliken i verksamhetsuppföljningen filtrerar på 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. Utanför sprintarna — nice to have, tas senare
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
Beslutad regel: AI-understödd analys ingår inte i sprintarna. Den är nice to have — det som byggs här är en generell uppföljning som kan passa alla intressenter. Beslutat på uppstartsmötet 31 augusti 2026.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. Första utkast av verksamhetsuppföljningen per enhet
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. E-post som notiskanal mergad till main i ärendelagret, och tilldelning blir en egen händelse
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. Notisfilter på tillagd label, så att MAS/MAR kan få e-post när hög HSL-risk sätts
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. Prenumerationsprofiler styr händelser till kanaler, och medlemmarna synkas per roll
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. Rapportören prenumererar automatiskt på sitt nya ärende med en egen profil
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. Sprint 2-grenen mergad till main med grön CI: sökindex, sökräknare och e-post till prenumeranter
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. Egen anställning används för att avgränsa platsvalet
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 Arbetsplatser måste underhållas manuellt Arbetsplatserna finns inte i organisationsträdet. De kan därför inte hämtas därifrån, utan måste underhållas som en egen label-struktur. Utrett i förberedelsesprinten — antagandet om MDViewer är motbevisat
Acceptanskriterier- Platsvalet körs mot label-strukturen, inte mot en sökning i organisationsträdet
- Lövnoder är valbara; en nod med underplatser tvingar ett val
orgIdoch ansvarig chef skrivs endast när valet ligger inom användarens egen anställning- Samma logik i både Katla och Draken, eftersom båda kan skapa avvikelseärenden
- Kvarstår: någon måste äga och underhålla platsstrukturen löpande
Slutsats som ändrar förutsättningarna. Underlaget antog att "det mesta som verkar behövas finns tillgängligt via MDViewer API". Det stämmer inte för arbetsplatser. Det gör manuellt underhåll av platsstrukturen till en förvaltningsuppgift som behöver en ägare, inte en teknisk detalj.Källa: förberedelsesprinten 10–17 aug 2026 · korrigerar Confluence sida 4
-
INT-04 DataWarehouseReader för chef och enhet Kopplar samman vilken chef som ansvarar för vilken enhet, och vice versa. AccessLoader mergad till main med grön CI, med IAF-konfiguration
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)
Beslutad regel: kopplingen fylls av tjänsten AccessLoader, som synkar samtliga användare och deras platser till access-mapper en gång per dygn. Blir någon anställd på en ny plats syns det dagen efter. Beslutat på standupen 3 september 2026.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. AD-uppslag med lokal fallback när personen inte finns i AD
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. Frågan är mindre akut sedan platsvalet slutade gå via trädnivåer, men kvarstår för behörigheten. Delvis överspelad — platsvalet går inte längre via trädnivåer
Acceptanskriterier- Platsvalet berörs inte längre — det körs mot label-strukturen (se INT-03)
- Behörighetsmodellen får fortfarande inte anta en fast trädnivå för enhet
- Öppen fråga kvar: hur enhetsnivån ska härledas för filtrering inom IAF
Kvarvarande del av frågan. Antas fel nivå ser fel personer fel ärenden. Det gäller nu bara behörighetsfiltreringen, inte platsvalet.Källa: Confluence sida 4 · delvis besvarad i förberedelsesprinten
-
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
Inga rader matchar filtret.
Dag för dag genom sprinten
Loggen förs varje sprintdag och är sprintens gemensamma minne. Varje inlägg har två delar: vad som sades på standupen, och vad som faktiskt levererades i kod. Här hamnar också beslut om arbetssätt, prioritering och dagens läge — beslut som ändrar en funktion skrivs i stället in på berörd rad i funktionslistan.
Uppstart
Dagen började med ett internt möte i utvecklingsteamet, före uppstarten med verksamheterna. Där gicks igenom vad som hänt sedan den tekniska förberedelsesprinten och vad som behöver arbetas vidare med. En punkt lyftes ut som ett eget spår: ett möte ska bokas om vilka informationssäkerhetsåtgärder sprinten behöver ta hänsyn till, eftersom uppgifterna som hanteras är klassade som klass 3.
Sedan följde uppstartsmötet med verksamheterna. Där landade också formerna för deltagandet: enhetscheferna kan inte vara med på många standupar, och är lediga onsdag till fredag under den första veckan. Övriga deltagare tar med sig deras perspektiv de dagarna.
Beslut
Uppföljning och statistik får en riktning. Under sprintarna byggs en generell uppföljning som kan passa alla intressenter. AI-understödd analys av fritext skjuts på — den är nice to have, inte det som avgör om lösningen fungerar. Rapporter i Qlik Sense utvecklas inte här; det arbetet hänvisas till BI-teamet vid ett senare tillfälle. (UPF-02, UPF-08, UPF-11)
Den löpande dialogen sker på standupen och i en Teams-kanal där alla deltagare finns. Det är där frågorna ställs mellan mötena.
Arkitekten är med som rådgivande — på standupen och när det behövs. UI/UX sitter med utvecklarna så mycket som det går under båda sprintarna.
Att göra: boka mötet om informationssäkerhet och vilka åtgärder klass 3-data kräver av sprinten.
Levererat i kod
Kodarbetet kom igång samma dag i två spår: rapportörens formulär i Katla, och den plats- och behörighetsmodell i ärendelagret som formuläret vilar på. Katla-arbetet ligger på en egen gren och är ännu inte i en pull request.
web-app-katla-sm
- En egen gren för sprinten öppnades med en genomgripande omarbetning av rapporteringsformuläret. Hopfällbara avsnitt är ersatta med fasta sektioner — rapporten fylls i uppifrån och ner och rubrikerna står kvar som orientering. Registreringssidan och det skapade ärendet delar nu samma sektionsordning, så att vyerna inte kan glida isär. (RAP-01)
- Rapporttyperna Avvikelse och Missförhållande har fått en förklarande text under namnet, så att de går att jämföra innan valet görs. (RAP-01)
- Valet av vem händelsen berör styr nu formuläret: brukarsektionen och wizardens brukarsteg visas bara när händelsen gäller en enskild brukare. Alternativet Annat är samtidigt borttaget — kvar är enskild brukare och grupp. (RAP-03)
- Ett schema för plats och händelseförlopp med tidpunkt för händelsen, beskrivning av förloppet och vidtagna åtgärder som obligatoriska fält. (RAP-03, RAP-04)
- Schemat hålls tills vidare i repot i stället för att hämtas från schema-API:t, så att ändringar i formulärets rubriker går att granska i en pull request och rullas tillbaka med koden. Vägen tillbaka till API:t är en rad. (KAT-10)
- Platsens förhandsval ur anställningen är tills vidare bortkopplat — rapportören söker fram platsen själv. Anställningen används fortfarande för att fylla i organisation och enhetschef när platsen ligger i den egna verksamheten. (RAP-04)
- En kvittosida efter inskickad rapport, utan åtgärdsknappar: rapporten är inne och det finns inget kvar att göra på den sidan. (RAP-01)
api-service-support-management
- Ett ärendes labels expanderas nu till hela sin förälderkedja innan behörighetsetiketterna beräknas. Det är maskineriet under platsval och åtkomst: en plats långt ner i strukturen bär med sig hela vägen upp, så att filtreringen kan ställa frågan på vilken nivå som helst. (RAP-04, KAT-03, BEH-05)
- Frågor mot ärendelagret på label, med tester. (BEH-05)
Standup
Teamet visade registreringsformuläret i Katla och gick igenom det ovanifrån: rapportörens egna uppgifter, typ av händelse — avvikelse eller missförhållande — vem händelsen berör, plats, tidpunkt, händelseförlopp, omedelbart vidtagna åtgärder och förslag på åtgärder. Berör händelsen en enskild brukare tillkommer ett steg där brukaren identifieras; annars gäller rapporten verksamheten. Platsen är enhet eller avdelning, och avdelningen går att söka fram direkt.
Obligatoriskt är plats, datum när händelsen upptäcktes, beskrivningen av händelseförloppet och de åtgärder som vidtogs omedelbart. Klockslag, liksom datum och tid för när händelsen inträffade, är frivilliga, och förslag på åtgärder får lämnas blankt. Beskrivningsfälten kräver ett minsta antal tecken.
Att spara ett halvfärdigt utkast finns inte — det togs bort på verksamhetens egen begäran — och frågan kom upp igen: stänger man ner fönstret är rapporten borta. Verksamheten ville ha en varning i stället, och så blev det. Har man börjat fylla i en registrering och stänger fönstret ska formuläret säga att uppgifterna inte sparas.
Knappen Skicka in och logga ut ska bort. Den kommer från antagandet att det står datorer på boendena som ingen är inloggad på, och ingen i rummet kunde peka på vad den tillför i dag. Frågan om delade telefoner kom upp och pekade samma väg: vid passbyte loggar nästa person in med sitt eget id — annars ser inskickade rapporter ut att komma från någon annan, och det problemet gäller alla system som kräver personlig inloggning.
Verksamheten frågade hur formuläret visar vad som saknas. I dag finns en visuell markering som ska förbättras. Mönstret som visades: ett enda missat fält tar rapportören direkt dit, medan flera samlas i en länklista längst upp. Verksamheten lyfte att mönstret ska vara detsamma i alla drakar, inte bara i den här — vilket också är avsikten.
Från backend redovisades gårdagens sortering av de AD-grupper som behörighetsmodellen kräver. Verksamhetschef, enhetschef, LEX-utredare, LEX-ansvarig och MAS/MAR behöver egna grupper, och de behövs dubbelt — för test och för prod — och separat för VoF och IAF, plus administratörsgrupper i båda miljöerna. Det landar på ett tjugotal grupper. I förberedelsesprinten fanns bara två testanvändare: en som såg allt och en som såg en enda avdelning. Nästa steg är att läsa in personerna och vilken plats var och en tillhör. Rollen avgör vad du får göra, platsen vilka ärenden du ser — och styrningen har två nivåer: vad som syns i ärendelistan, och vad som syns inne i ett ärende, där den blir finkornigare.
Dagens arbete är att fortsätta med behörighetsgrupperna, som inte blev klara, och att finslipa registreringsformuläret — bland annat ska skicka-in-knappen följa med hela vägen ner i formuläret. Verksamheten ombads testa: en länk till testmiljön kommer i chatten under dagen, tillsammans med uppgifter för ett test-id. Miljön nås inifrån kommunens nät, och teamet skriver i chatten när den uppdateras och kortvarigt ligger nere.
Beslut och öppna frågor
Platsen förväljs inte. Rapportören ska alltid välja plats aktivt. Bakgrunden är dubbel. Tekniskt: eftersom många enheter har avdelningar måste rapportören ändå välja avdelning, så ett förval på enhetsnivå sparar inget steg. Verksamhetens skäl väger tyngre — i Flexite väljs den enhet där rapportören har sin anställning automatiskt, och det blir fel. En avvikelse ska hanteras på den enhet där den inträffade, inte hos rapportörens egen chef, och ett förval som blir fel fördröjer hanteringen. Invändningen att verksamheter ser olika ut möttes med att systemet ska fungera för alla, och att den som rapporterar vet var hen arbetar. (RAP-04)
Skicka in och logga ut tas bort, en varning kommer i stället. Knappen fyller ingen tydlig funktion i dag. Den som har påbörjat en registrering och stänger fönstret ska i stället varnas om att uppgifterna inte sparas. (RAP-01)
Att göra: avdelningslistan behöver fyllas på. IAF har avdelningar som inte är kända, och tillägg väntas även på VoF-sidan. Arbetsplatserna finns inte i organisationsträdet och underhålls manuellt. (INT-03)
Levererat i kod
Tre spår: rapportörens formulär i Katla, labelstrukturen i ärendelagret som platserna vilar på, och ett nytt repo för tjänsten som ska fylla behörighetsmodellen med organisationsdata.
web-app-katla-sm
- Varningen vid stängning är byggd. En krok bevakar om rapporten bär innehåll, och webbläsaren frågar innan fliken stängs eller sidan laddas om. Navigering inne i appen går i stället via avbryt-dialogen, som redan fanns. Enhetstest på innehållskontrollen. (RAP-01)
- Knappen Skicka in och logga ut är borta — texten och båda anropen är ute ur gränssnittet. (RAP-01)
- Registreringen fick ny formgivning: en samlad felsammanfattning när något saknas, tydligare rubriker, och en språklikriktning där ärende blivit rapport i det rapportören ser. Kravtexter för brukare och kollega när de behöver läggas till. (RAP-01, RAP-03, RAP-06)
- Anställningsform per part — tillsvidareanställd eller vikarie — både för rapportören och för kollegan man rapporterar åt, med tillsvidareanställd som förval. (RAP-11)
- Överblicken byggd om: statusnavigeringen flyttad ur sidfiltret till en egen lista, nytt tabellhuvud, och mobilvyerna omarbetade. (RAP-07)
- Tidsfältet, avbryt-dialogen och e2e-testerna för registrering och överblick justerade i samma svep.
api-service-support-management
- Labelstrukturen, den som bär platserna, tålde inte cykler: jämförelsen mellan två labels gick i oändlig rekursion på ett träd som pekade på sig självt. Cykeldetektering på plats, och sökvägen genom trädet räknas om när strukturen ändras. Ligger nu i main. (INT-03, MOD-06)
- Labels har fått ett versionsfält, så att två samtidiga ändringar av samma ärendes labels inte skriver över varandra tyst — den som sparar sist får veta i stället. Databasmigrering och uppdaterade integrationstester. (MOD-06, KAT-10)
api-service-access-loader
- Ett nytt repo lades upp för AccessLoader — tjänsten som ska läsa in organisationsdata i behörighetstjänsten access-mapper: personerna, och vilken plats var och en tillhör. Så här långt är det mallens tjänsteskelett, utan egen logik. (BEH-04, BEH-05, INT-04)
Standup
Dagen började med demo av det nya utseendet. Överblicken är fortfarande en tabell med rapportörens egna rapporter, inskickade och avslutade, med ny rapport högst upp. I registreringen väljs platsen nu direkt i sökningen, och felhanteringen är omgjord: försöker man skicka in med något ofyllt pekas fältet ut, och skicka-knappen följer med ner i formuläret.
Anställningsformen visades för första gången — tillsvidareanställd eller vikarie, både för rapportören och för kollegan man rapporterar åt. Det var ett krav, men uppgiften finns inte att hämta någonstans. I personaldatan står yrkestiteln och inget mer: vårdbiträde, punkt. Att någon är vikarie framgår bara indirekt av var i organisationsträdet anställningen hänger, och det är data som måste sys ihop på annat sätt. Behovet är uppföljning: att kunna se om det är vikarier som rapporterar. På sommaren kommer fler avvikelser, och då behöver informationsinsatserna kunna riktas rätt. Valet ligger kvar i formuläret, och teamet gör ett försök till att läsa ut uppgiften ur källan innan det blir permanent.
Under rapportören låg en möjlighet att redigera e-postadress och telefonnummer, och den ska bort. Tre invändningar pekade samma väg. Vid utlämnande av allmän handling går det inte att avgöra om ett nummer är privat eller tjänstenummer — och den situationen har redan uppstått. Över nittio procent av dem som rapporterar på utförarsidan har ingen personlig telefon, så numret hamnar ändå på en enhet. Och utredare kontaktar personal via chefen, som redan har uppgifterna. Konsekvensen togs med öppna ögon: saknas kontaktuppgifter finns inget sätt att avisera en rapportör om att en komplettering begärts. Hen ser det vid nästa inloggning, och i övrigt går vägen via chefen, som i dag.
Personnummer på brukaren diskuterades länge, och landade i att ingenting ändras. Så fungerar det nu: rapportören skriver ett personnummer, och uppgifterna hämtas via Meta som i sin tur hämtar från folkbokföringen. På sikt är tanken att hämta från LifeCare i stället, men den möjligheten finns inte i dag. Invändningen var risken att någon i stress skriver fel och registrerar en rapport på en person som inte ens finns i verksamheten. Mot det står att hälso- och sjukvårdssidan alltid har en patient med personnummer, att numret är vägen in i journalen vid granskning, och att rapporterna blir godtyckliga att sortera in i akterna utan det. Personnumret i sig är inte det känsliga — det är namn och folkbokföringsadress som lämnar systemet. Frågan om vilken katalog man får söka mot lämnas till informationssäkerhetsklassningen, där den hör ihop med mötet om klass 3-data.
Två saker teamet tar med sig från den diskussionen: att kunna ta bort ett felaktigt personnummer från ett ärende utan att förlora ärendet, och att en person som skrivs in manuellt med bara namn inte ger den automatiska kopplingen till tidigare avvikelser. Den kopplingen kommer först när enhetschefen kompletterar med personnummer, vilket rapportören inte kan göra själv.
Ordningen i formuläret avgjordes. Ska rapportören eller typen av rapport komma först? Vissa ville se rapporttypen först, eftersom plattformen längre fram ska bära även synpunkter och klagomål, och man då behöver veta vilken sorts rapport man håller på med. Andra tycker att det är naturligt att den som rapporterar står först, precis som i dagens system. Det blev rapportören först: kommunens e-tjänsteplattform har den ordningen i över tvåhundra e-tjänster, och ett kommungemensamt ärendehanteringssystem förutsätter att flödet ser likadant ut överallt.
Till sist textarbete. Ordet anmäler ska bort ur formuläret — det är värdeladdat, och det heter rapportera. En tidpunkt framåt i tiden går att välja, vilket den inte ska. Och fler testpersoner ska läggas in så att verksamheten kan prova med mer än ett konto.
Beslut och öppna frågor
Redigera kontaktuppgifter tas bort, både på rapportören och på kollegan man rapporterar åt. Systemet visar det personaldatan ger, inget annat. (RAP-06)
Anställningsformen väljs i formuläret så länge den inte går att härleda. Teamet undersöker källan en gång till. (RAP-11)
Rapportören kommer först, därefter typ av rapport. (RAP-01)
Personnummer på brukaren behålls oförändrat. Frågan om katalog och sökning avgörs av informationssäkerhetsklassningen. (RAP-03, MOD-09)
Att göra: byta anmäler mot rapportera, stoppa framtida tidpunkter, och lägga in fler testpersoner i testmiljön.
Levererat i kod
Två spår: Katla, som nu har två utvecklare på formuläret, och ärendelagret, där versionsfältet på labels gick igenom granskning och landade i main.
web-app-katla-sm
- Anställningsformen sätts nu automatiskt i stället för att väljas. Radiogruppen är borttagen, och formen härleds i backend ur anställningen, med enhetstest på härledningen. (RAP-11)
- Rapporttypen sätts som label för båda typerna. Tidigare sattes den bara vid missförhållande, och då som en ensam nod — avvikelser gick in helt utan rapporttyp, och läsningen tillbaka tolkade avsaknaden som avvikelse, vilket dolde att uppgiften saknades. Nu skickas kedjan rapporttyp följt av vald typ, på samma sätt som platsen, med tillbakafall för ärenden som registrerats innan dess. (RAP-01, MOD-06)
- Rättelser i backend runt att skapa ärendet, med utökade feltester. (INT-01)
web-app-katla-sm
- Möjligheten att redigera uppgifter på en part är borta ur gränssnittet — e2e-testerna kontrollerar nu att knappen inte finns någonstans. Parter går fortfarande att ta bort. (RAP-06)
- Notispanelen förenklad och har fått ett test för sitt feltillstånd. Hjälptexterna i formuläret putsade, på svenska och engelska. (RAP-01)
api-service-support-management
- Versionsfältet på labels gick igenom granskning och ligger nu i main: migreringen flyttad, ärendetjänsten och API-resursen rättade efter kommentarer, med nya tjänstetester och uppdaterad API-beskrivning. (MOD-06, KAT-10)
Standup
Backend-dagen gick till behörighet. Frågan om hur alla användare ska laddas in har landat i en väg framåt som nu implementeras: access-mapper, tjänsten som bär behörigheterna, fylls med samtliga användare och synkas en gång per dygn — blir du anställd någonstans ser du det du ska se dagen efter. Arbetet ligger i den nya tjänsten AccessLoader och är ännu inte pushat. Parallellt är delar av den parameterstyrda åtkomstkontrollen implementerad.
Teamet slutade vänta på testanvändare och satte upp egna i går, så nu finns flera användare med olika behörighet att prova med. Det gav utfall direkt: en bugg mellan rapportörens vy och de med lägre läsbehörighet hittades och rättades, och går ut med nattens körning. Mycket av arbetet är konfiguration som inte syns i gränssnittet.
Hur systemet ska veta vem som är chef har fått sin form. Utgångspunkten är inte rapportören utan platsen: systemet tittar på en anställd på avdelningen, frågar vem som är chef för den, och får därigenom ut enhetschefen. För verksamhetschefen är det chefens chef. Verksamheten bekräftade att det är precis så det måste fungera — legitimerad personal arbetar på flera ställen, och en avvikelse som inträffat på en annan enhet ska inte hanteras av personalens egen chef utan av chefen där det hände. Två hål är kända: vikarier har inte den strukturen och måste välja plats, och den som står som enhetschef i systemet är inte alltid den faktiska — där behövs en annan väg att hitta rätt.
Frågan om chefen som rapportör togs upp och avgjordes. Att en chef rapporterar i sin egen verksamhet är inget märkligt — snarare en förutsättning. Men hur ska ärendet fördelas? Ingen automatik byggs: har enhetschefen själv rapporterat och ärendet ska till verksamhetschefen, tilldelas det manuellt på vanligt sätt. Dubbla roller slås samman i behörighetsmodellen, så den som är både rapportör och enhetschef inte får en beskuren vy. Och enhetschefer ska inte registrera via Katla alls — de skapar ärendet i handläggningsdraken. Det är samma mönster som de befintliga drakarna, och en förberedelse för de ärendetyper som aldrig kommer in via Katla.
När någon rapporterar åt en kollega är det kollegan som blir rapportör, inte den som satt vid tangentbordet. Det är den som identifierat avvikelsen som ska stå för den — och det är också den som kan logga in och se vad som lämnats in, och som notiser och begärd komplettering ska gå till. För vikarier utan kontaktuppgifter gäller det som sades i går: då får enhetschefen ta reda på vem som ska pratas med.
Handläggningssidan är under utbyggnad men inte redo att testas. Strukturen finns, hämtad ur skisserna, och det går att registrera, se ärendet komma in och öppna det — men inte att driva handläggningen. Den demas för chefer i dag, uttalat för kännedom och inte för test. Katla väntar också en stund: alla textändringar är inte synkade ännu.
Till sist texterna, igen. Mycket är ändrat men inte allt, och flera ord är för svåra för dem som ska använda formuläret — händelseförlopp och åtgärdsplan nämndes. Ett eget möte bokas under dagen, utanför standupen, med utgångspunkt i det som arbetades fram tillsammans i fredags. UX äger avgörandet: teamet försöker komma överens, och gör det inte det vinner UX.
Beslut och öppna frågor
Chefen härleds via platsen, inte via rapportören. (FLO-05, INT-04)
Ingen automatik när chefen själv rapporterat — ärendet tilldelas manuellt om det ska vidare. Dubbla roller slås samman. (BEH-01, BEH-05)
Enhetschefer registrerar i handläggningsdraken, inte i Katla. (BEH-01)
Den man rapporterar åt blir rapportör. (RAP-06, RAP-07, NOT-05)
Anställningsformen sätts automatiskt — ersätter gårdagens beslut om att den anges i formuläret. (RAP-11)
AccessLoader synkar en gång per dygn. (INT-04)
Att göra: mötet om hjälptexterna, och en väg att hitta faktisk enhetschef där systemets uppgift är fel.
Standup
Fredagen inleddes med en genomgång av gårdagens spår. Behörighetsarbetet gick framåt i AccessLoader, och nästa steg är integrationen mot access-mapper och att börja ladda in organisationsdata. Parallellt gjordes en optimering i behörighetshanteringen.
Dagens tyngdpunkt ligger inte i formuläret utan i ärendelagret: den tekniska implementationen av åtgärder på ett ärende. Att få det att fungera är inte problemet — det gör det redan. Frågan är hur det ska byggas för att vara förvaltningsbart och hålla över tid. Fler verksamheter än den här har åtgärdshantering, och lösningen ska helst bära för alla. Gårdagen gick i stort åt till att diskutera lösningar och gav ett utgångsläge som teamet räknar med att kunna sätta ner foten på i dag. Ambitionen är uttalad: att inte måla in sig i ett hörn, utan bygga rätt från början.
Frågan om omedelbart vidtagna åtgärder ska vara obligatoriskt togs upp av verksamheten och avgjordes. Fältet — det som beskriver vad rapportören gjorde när hen fick kännedom om händelsen — hade blivit tvingande, och verksamheten ville veta om det var ett medvetet val. Svaret blev nej: fältet står kvar, men görs frivilligt. Alla avvikelser går inte att knyta till en akut åtgärd i stunden. En del rör längre förlopp där kännedomen kommer i efterhand, och då går det varken att datera händelsen eller peka på vad som gjordes direkt. Ett tvingande fält ger i det läget inget innehåll, bara en punkt i rutan. Att över huvud taget skriva avvikelsen är i många fall åtgärden. Invändningen från hälso- och sjukvårdshållet — att det där är viktigt att beskriva vad som gjorts akut — noterades, men fältet finns kvar för den som har något att skriva, och enhetschefen fyller ändå i sina omedelbara åtgärder i nästa steg.
Hjälptexterna under rubrikerna har landat. Verksamheten ville att förklaringarna av avvikelse och missförhållande skulle visas först vid klick; UX höll fast vid att de ska synas direkt, av tillgänglighetsskäl. Verksamheten gav med sig. Argumentet som avgjorde var att den som är osäker behöver kunna jämföra de två alternativen mot varandra innan valet görs — måste man klicka fram ett i taget ser man bara det ena, och valet blir ett stressmoment i stället för en vägledning. Upplägget prövas som det är, och blir bilden för rörig går texterna att plocka bort. Frågan tas upp igen när formuläret testas med riktiga användare.
Textarbetet i övrigt är i hamn — de som drev frågan om ordval är överens efter en egen dialog utanför standupen.
Beslut och öppna frågor
Omedelbart vidtagna åtgärder blir frivilligt. Fältet står kvar. (RAP-03)
Hjälptexterna under rubrikerna står kvar synliga. Omprövas vid test med riktiga användare. (RAP-01)
Att göra: sätta formen för hur åtgärder implementeras tekniskt på ett ärende, så att den bär även för andra verksamheter. (ATG-01, ATG-08)
Levererat i kod
Dagens beslut om omedelbara åtgärder var i koden inom timmen. I övrigt gick förmiddagen till formulärets fältmärkning och datumvalidering, och till att göra label-strukturen flyttbar i ärendelagret.
web-app-katla-sm
- Fältet för omedelbara åtgärder är inte längre obligatoriskt, i linje med dagens beslut, och textfältens höjd går att styra per fält. (RAP-03)
- Obligatoriska och frivilliga fält märks ut i klartext i stället för med symbol. (RAP-01)
- Datumfälten validerar att tidpunkten ligger inom rimliga gränser, med tydligare hjälptext och egna felmeddelanden. (RAP-03)
api-service-support-management
- Labels kan flyttas i strukturen: en egen arbetare hanterar flytten och ärendetjänsten uppdaterar berörda ärenden. (MOD-06)
- Metadata-API:t för labels är omarbetat i samma spår. (MOD-06)
api-service-access-mapper
- Städning efter rebase på grenen för åtkomstgrupper. (INT-04)
Standup
Helgen och fredagseftermiddagen gav lite. Inga nya funktioner, bara småjusteringar — och det är avsiktligt. Tyngden ligger i diskussionerna om hur beslut och åtgärder ska hanteras tekniskt, och den grunden måste vara på plats innan gränssnittsändringarna läggs på. Väl där räknar teamet med att själva gränssnittsarbetet inte tar lång tid.
Förmiddagens uppgift är därför uttalad: bestämma vägen framåt för den tekniska lösningen, och sedan bygga vidare. Frågan har hängt sedan i torsdags och blir inte enklare av att vänta.
I behörighetsspåret fortsatte laddningsjobbet och väntas vara klart för test under dagen. API:t är uppdaterat och ligger som en PR.
Verksamheten har lämnat feedback på texterna och förslag på ändringar i gränssnittet. Varken UX eller den som skrivit texterna hann gå igenom dem under helgen — båda gör det under dagen och stämmer av med varandra, och teamet återkopplar.
Frågan om hur brukaren pekas ut togs upp igen. Verksamheten vill helst att sökningen sker mot de brukare som är aktuella hos kommunen, inte mot hela metakatalogen — ju mindre register man slår mot, desto mindre risk att få in fel person. Svaret var entydigt men obekvämt: den integrationen ingår inte i den här sprintens scope, den hör hemma i det större arbetet med verksamhetssystemet. Kvar står två vägar — personnummersökning mot metakatalogen som i dag, eller att ta bort personnummersöket helt och lämna ett fritextfält för namn utan teknisk koppling. Applikationen lagrar i sig inga personnummer; de växlas mot ett id.
Invändningen från hälso- och sjukvårdshållet var att det för deras del inte finns något val: HSL-insatser görs aldrig utan personnummer, så för HSL-avvikelser är personnumret utgångspunkten, utifrån hälso- och sjukvårdslagen. Från verksamheten kom samtidigt kravet att en avvikelse som rör en brukare måste gå att spåra tillbaka till personens akt — det behöver finnas en koppling, id eller personnummer, annars går det inte att i efterhand hitta rätt avvikelser på rätt person. Frågan lyfts till säkerhetshåll för guidning innan ett förslag tas fram.
Beslut och öppna frågor
Integration mot verksamhetssystemet ingår inte i sprintens scope. Sökning mot aktuella brukare hör hemma i det större arbetet med verksamhetssystemet, inte här. (RAP-03)
Öppen fråga: personnummersökning mot metakatalogen. Antingen står den kvar som i dag, eller så tas den bort helt till förmån för ett fritextfält utan teknisk koppling. Säkerhetsbedömning hämtas in först, sedan tas ett förslag fram. (RAP-03)
Att göra: sätta formen för hur beslut och åtgärder implementeras tekniskt — kvarstår från fredagen och blockerar gränssnittsarbetet. (ATG-01, ATG-08)
Att göra: gå igenom verksamhetens förslag på texter och gränssnitt och återkoppla. (RAP-01)
Levererat i kod
Dagens kod ligger på två håll. Rapportörens e-tjänst byggdes om på designsystemets egna layouter, och i handläggningsdraken tog behörigheten steget från att vara av eller på till att skilja på att läsa och att ändra — bakifrån i ärendelagret och framifrån i utredningsflikarna, samma dag.
web-app-katla-sm
- Rapportflödet är ombyggt på Astryx egna responsiva layouter i stället för egna lösningar — ruttlogik, vyhantering och radinteraktion kommer nu från designsystemet. (RAP-01)
- På mobil komprimeras ärendets identitet till en rad, med plats reserverad för statusen så att rubriken inte hoppar. (RAP-07)
- Inblandade parter visas som kompakta personsammanfattningar, och kontaktlänkarna går att använda även när ärendet är låst. (RAP-03)
- Formulärets åtgärdsknappar ligger kvar synliga när formuläret rullar, och ett fält som får fokus hamnar aldrig bakom dem — hela textrutan rullas fram. (RAP-01)
- Notishistoriken är komprimerad, dess rubrik nåbar, och fokusmarkeringen densamma överallt. (RAP-07)
- Katla får Sundsvallsdraken som kännetecken. (RAP-01)
- Tillgänglighetsstödet i det befintliga gränssnittet och en härdning av bygg- och sessionskonfigurationen mergades till main.
web-app-draken-public
- Utredningen delas efter ägare: enhetschefens del, SoL/LSS-delen och HSL-delen härleds ur användarens AD-grupper, och den del man inte äger lyfts ur flikraden helt i stället för att ligga låst. Ärendelagret nekar läsningen på samma regel, så det är två spärrar och inte en. (UTR-01, LEX-01, BEH-11)
- Andra steget skiljer läsa från ändra: en roll kan läsa en utredning den inte får skriva i. Dokumentet behåller då sin flik och renderas skrivskyddat, till skillnad från ett dolt. Det är precis vad rollerna behöver — MAS/MAR och LEX-utredaren äger var sin utredning och läser de andras. (HSL-02, BEH-11)
- Saknad konfiguration lämnar allt synligt och redigerbart som förut; en felaktig konfiguration stoppar uppstarten i stället för att tyst låsa ett formulär.
api-service-support-management
- Fältbehörighet kan hållas till läs. Tidigare var ett fältutlämnande allt eller inget — såg man en nyckel fick man ändra den. Nu kan behörigheten bära en nivå, och den kan bara smalna av, aldrig vidga. (BEH-04)
- Skrivning prövas i två frågor: en nyckel man inte ser nekas som förut, en nyckel man ser men inte får ändra nekas bara när ändringen faktiskt ändrar något — så en handläggare kan spara tillbaka det ärende hen fick serverat. (BEH-04)
- Fasbyte och statuskontroll är ett och samma anrop: ett ärende som flyttas bedöms på den status det kommer att ha, inte på om begäran råkar nämna någon. (FLO-01)
api-service-support-management
- Arbetaren som flyttar labels asynkront är inkopplad. (MOD-06)
- Fortsatt arbete med utskick och utkorg i det delade ärendelagret, efter granskning.
api-service-access-mapper
- Access-user bär nu sitt ursprung, och entiteten är uppdaterad tillsammans med en rättning i flyway-migreringen. (INT-04)
Standup
Behörigheten saknades — det upptäcktes i går och byggdes samma kväll. När ett ärende handläggs har olika roller olika flikar, och det räckte inte att styra vem som ser vad: läsa och ändra måste gå att skilja åt. Backend konfigurerades upp under morgonen, så datan är skyddad där. Även gränssnittet låser nu flikarna mot rätt grupp, redan innan ärendet sparats första gången, men hann troligen inte ut i testmiljön. Under dagen valideras att allt beter sig som tänkt.
Åtgärdsmodellen — den som blockerade i fredags och i går — är fixad och dokumenterad, och implementeras under dagen. Laddningsjobbet i behörighetsspåret fortsatte parallellt.
Merparten av avstämningen gick åt till verksamhetens textförslag. De är genomgångna, flera justeringar redan gjorda, och de kommentarer som blivit frågor gicks igenom punkt för punkt på delad skärm. Ett fåtal frågetecken står kvar och verksamheten återkopplar under dagen.
Utredningsflikarna byter namn. Utredning SoL/LSS blir Lex Sarah och Utredning HSL blir Händelseanalys HSL. Förslaget kom från verksamheten och bekräftades på plats av hälso- och sjukvårdshållet: att en händelseutredning inleds betyder inte att det blir en anmälan, och händelseanalys säger vad som faktiskt görs.
Kategoriseringen görs en gång, av enhetschefen. När ett ärende som kommit in som avvikelse bedöms som misstänkt missförhållande följer chefens kategorisering med in i LEX-processen, och LEX-utredaren ändrar inget i enhetschefens flik. Alternativet — dubbel kategorisering — avvisades: ett ärende skulle då bära två olika kategoriseringar och statistiken blir inte tolkbar. Verksamheten höll med, och pekade på att LEX-utredaren ändå lägger sina egna orsaker längre ned i flödet och att de också går ut i statistiken. Kategoriseringen går att ändra i dialog med enhetschefen ända fram till att ärendet avslutas.
Kom rapporten in som missförhållande gör LEX-utredaren hela kategoriseringen — både lagrum och kategorier. Skälet är att verksamheten vill kunna koppla kategorisering till lagrum, och att lägga de två på olika håll ger en mer komplex lösning utan att någon vinner på det. Utredarhållet bekräftade att det fungerar.
Verksamhetschefen saknar knappen ”Redo för beslut”. Flödet verksamheten beskrev: en enhetschef som är osäker på om underlaget räcker skickar upp ärendet till sin verksamhetschef, som gör bedömningen. Det fungerar redan systemmässigt — ärendet tilldelas verksamhetschefen, som därmed har bollen och kan driva det vidare, lägga till åtgärder eller lämna tillbaka det — men knappen finns bara i enhetschefens vy. Den ska se likadan ut på båda nivåerna. Gäller avvikelser.
Vad ”beslut” betyder togs upp och blev en längre diskussion. Verksamheten menar med beslut det formella beslutet: grad av missförhållande, om en utredning ska inledas eller inte, om en anmälan ska göras. De ligger i delegationsordningen och måste gå att följa upp — hur många beslut om missförhållande som fattats under ett år är en fråga som återkommer, och de siffrorna får inte blandas ihop med enhetschefernas processteg. I Draken är beslutsfasen i stället ett läge i processen: den säger var ärendet står, inte vad som beslutats, och gör det synligt vilka enheter som aldrig tar sina avvikelser hela vägen — ett problem verksamheten känner igen i dag. Verksamheten köper Drakens begrepp. Kvar står frågan om de formella besluten behöver gå att hämta ut samlat; behovet finns, och det måste i så fall tänkas in nu i stället för att sammanställas i efterhand.
LOV-utförarna får inte glömmas bort. För privata utförare ska bara HSL-avvikelser hanteras i enhetschefsvyn — SoL- och LSS-avvikelser hör inte dit, och ett missförhållande kan aldrig bli aktuellt för en LOV-utförare, som heller aldrig får skicka vidare till verksamhetschef. Eftersom rapportören inte klassar kommer fel saker att komma in ändå. Delvis är det en utbildningsfråga. Systemsvaret i dag är att ärendet alltid går att stänga, redan i granskningsfasen, med en obligatorisk motivering som blir kvar som tjänsteanteckning. Hur felskicket hindras i första hand är inte utrett.
Beslut och öppna frågor
Utredningsflikarna heter Lex Sarah och Händelseanalys HSL. (LEX-01, HSL-02)
Enhetschefens kategorisering är den som gäller för ärendet. LEX-utredaren ändrar den inte, men kan begära ändring i dialog med chefen fram till avslut. (UTR-02, LEX-04)
Vid rapporterat missförhållande gör LEX-utredaren både lagrum och kategorisering. (MOD-03, LEX-03, LEX-04)
Verksamhetschefen får samma ”Redo för beslut” som enhetschefen. (BEH-07, FLO-03)
Öppen fråga: vad enhetschefens utredning ska heta. Verksamheten upplever ”utredning på utredning” när både chefen och LEX-utredaren utreder. Tekniskt går det att skilja på namn och mall beroende på om ärendet är en avvikelse eller ett missförhållande — utredningarna ligger redan i separata scheman. Verksamheten återkommer med förslag. (UTR-01)
Öppen fråga: ska de formella besluten gå att hämta ut samlat? (MOD-08, LEX-08)
Öppen fråga: var anmälan och dess ärendenummer ska dokumenteras — under utredningen eller i beslutsfasen. (MOD-05, LEX-09)
Öppen fråga: hur LOV-utförarnas vy avgränsas till HSL. (BEH-05, BEH-06)
Att göra: frågan om rapportörens sökning på personnummer tas med gruppen för informationssäkerhet — möte inbokat 14 september. (RAP-03)
Att göra: verksamheten skickar skärmbilder med markering för de två punkter där det är oklart vilket block i gränssnittet som avses.
Levererat i kod
Dagen delades mellan behörighet och åtgärder. I e-tjänsten lades en gemensam Katla-plattform under de flöden som byggdes om i går, och i handläggningsdraken kopplades utredningsflikarna till AD-grupper. Åtgärdsmodellen fick sin egen gren i ärendelagret.
web-app-katla-sm
- En delad Katla-plattform med en behörighetsstyrd katalog ligger nu under e-tjänsten, och gårdagens Astryx-flöden är integrerade i den. (RAP-01, RAP-07)
- Inloggningsrubriken bryter korrekt vid förstorad text, och fynd från plattformsgranskning och Sonar är åtgärdade. (RAP-01)
api-service-support-management
-
Egen sprintgren för åtgärder:
Measurebär nu sin åtgärdstyp som identifierare, ochMeasureEntityhar versionshantering. Det är den modell som diskussionen sedan i fredags gällde. (ATG-01, ATG-08)
api-service-access-loader
- Logik för att ladda in chefernas behörigheter. (INT-04, BEH-12)
web-app-draken-public
- Vilka handläggare ett ärende kan tilldelas konfigureras genom AD-grupper, med uttalat fallback-beteende. (FLO-05, BEH-08)
- Utredningen kräver explicita val och öppnade sektioner i stället för tysta standardvärden. (UTR-02, UTR-05)
- Schemafälten är harmoniserade mellan etiketter och beskrivningar — grunden för de textändringar som nu kommer in. (UTR-01)
- Draken pekar mot SupportManagement API 16.0, där behörigheten på fältnivå finns. (INT-01)
Standup
Avstämningen ägnades nästan helt åt en förändring som inte diskuterats mycket tidigare: var åtgärderna ska ligga i gränssnittet. I skissen låg de längst ned i respektive utredningsflik — enhetschefens, Lex Sarah och Händelseanalys HSL. Det fungerar inte tekniskt, eftersom åtgärderna inte ska vara en del av utredningens schema. De flyttas därför till en egen flik, efter utredningen. Den visades på delad skärm, mer som koncept än med färdiga fält.
I den nya fliken samlas alla åtgärder på ärendet under varandra, och det syns vilken roll och vilken person som lagt till varje åtgärd. Eftersom åtgärdstyperna hör till rollen — enhetschefen har andra typer än HSL — väljer den som har flera roller först vilken roll hen arbetar i. Alla som arbetar med ärendet fyller på i samma yta och ser varandras åtgärder; behövs det kan åtgärdstyper låsas per person. Verksamheten tyckte att det lät som en utmärkt idé, och hälso- och sjukvårdshållet bekräftade att det betyder att en HSL-utredare kan lägga till åtgärder i samma ärende medan chefen arbetar med det.
Åtgärder över tid. Verksamheten beskrev ett känt problem: åtgärder beslutas, handlingsplaner görs och görs om, och när en ny chef tar över finns ingen koll på vad som redan beslutats — samma saker görs igen. Svaret var att fliken gäller ett ärende, och att en ny chef som får tillgång till en plats ärver ärendena och därmed deras åtgärder. En samlad bild av tidigare åtgärder per enhet är ett annat behov, som hör till verksamhetsuppföljningen. Samtidigt måste en handlingsplan för ett enskilt missförhållande gå att skriva ut, till exempel till IVO, utan andra åtgärder som ligger på enheten — och där hjälper det att åtgärderna hålls per ärende.
Hur handlingsplanen kommer till. Efter ett missförhållande föreslår LEX-utredaren åtgärder och sätter sig med chefen: vem är ansvarig, vem gör vad och när, och när det ska följas upp. För avvikelser är det enklare — åtgärder läggs upp och följs upp efter en tid. En åtgärd kan accepteras eller nekas, och den som nekar måste motivera varför. En nekad åtgärd hör inte hemma i handlingsplanen, men den ska sparas: historiken ska finnas kvar, också när handlingsplanen tas ut som PDF.
Vad som hör till handlingsplanen. Rapportörens omedelbara åtgärder kommer in som fritext; det är chefen som tolkar texten och för in dem i åtgärdsfliken, med samma struktur. Verksamhetens textförslag att tala om genomförda och planerade åtgärder i stället för omedelbara och planerade kom upp igen, och ledde till frågan om genomförda åtgärder ska med i handlingsplanen. Verksamhetens syn: en handlingsplan är det som ska göras — statistik över genomförda åtgärder vill man ändå ha, för att se vad som har effekt. Teamets invändning: tas planen ut sent kan viktiga åtgärder redan vara klara, och sorteras de bort visar planen inte längre vad som planerades. Klargörandet löste det: genomförd i den meningen är bara det som vidtogs omedelbart i samband med händelsen. Allt annat är planerat, även när det sedan blivit klart. Sorteringen går alltså på omedelbar eller planerad, inte på om åtgärden är klar. Verksamheten lade till att handlingsplanen oftast görs i samband med utredningen, att åtgärderna kan löpa länge i Lex Sarah-ärenden, och att IVO:s granskning gäller att ärendet utretts och att handlingsplanen anger ansvarig — inte vilka typer av åtgärder som valts.
Åtgärder eller Handlingsplan? Verksamheten lutade åt Åtgärder — det är det som gjorts eller ska göras, och handlingsplanen är nästa steg, utskriften som följer med händelseutredningen. Teamet bygger fliken som den ser ut nu, och verksamheten vill se den visuellt innan formen sätts. Sådana ändringar går snabbt. Det är inte dags att testa än, men det närmar sig.
Beslut och öppna frågor
Åtgärderna flyttas ut ur utredningsflikarna till en egen flik. Alla roller arbetar i samma yta, varje åtgärd visar roll och person, och den som har flera roller väljer först vilken roll hen agerar i. (ATG-01, UTR-06, LEX-06, HSL-05)
Åtgärdsfliken gäller ett ärende. En samlad bild av tidigare åtgärder per enhet hör till verksamhetsuppföljningen. (UPF-06, UPF-10)
Handlingsplanen byggs av de planerade åtgärderna. Omedelbart vidtagna åtgärder hålls isär; en planerad åtgärd följer med även när den är klar. (ATG-05)
En nekad åtgärd tas inte med i handlingsplanen, men sparas med sin motivering. (ATG-04, ATG-05)
Öppen fråga: ska fliken heta Åtgärder eller Handlingsplan? Verksamheten ser den byggd först. (ATG-05)
Levererat i kod
Åtgärdsspåret och behörigheten gick vidare i ärendelagret. En åtgärdstyp kan nu höra till flera grupper — i linje med avstämningens slutsats att typerna följer rollen — och klienten kan fråga vad användaren får göra med ett ärende innan något sparats. I handläggningsdraken blev utredningens felhantering tydligare.
api-service-support-management
- En åtgärdstyp kan höra till flera grupper i stället för en, med egen tabell och migrering. Det är grunden för att åtgärdstyperna styrs av roll. (ATG-01)
api-service-support-management
- Ett nytt anrop svarar på vad den inloggade användaren får göra med ett visst ärende, så att gränssnittet bara visar de kontroller som faktiskt skulle godkännas — också om ett utredningsformulär är redigerbart innan något sparats i det, vilket ärendet självt inte kan svara på. (BEH-04, BEH-11)
- Svaret hämtas ur samma regler som skrivvägarna redan upprätthåller, och ett test håller de två i lås över alla kombinationer — svaret kan aldrig lova åtkomst som ett anrop sedan nekas. (BEH-04)
- Nya fält eller skyddade resurser ändrar inte längre API-kontraktet; de tillåtna värdena finns i ett eget anrop. (INT-01)
api-service-support-management
- Fortsatt arbete med utskick i det delade ärendelagret: granskningskommentarer åtgärdade och integrationstester för massutskick via e-post.
api-service-access-mapper
- Användare i behörighetstjänsten kan filtreras på mönster, med en rättning för matchning mot korta mönster. (INT-04, BEH-12)
web-app-draken-public
- Utredningen sammanfattar sina valideringsfel och leder direkt till de fält som inte är korrekt ifyllda. (UTR-01)
web-app-draken-public
- Avsnittet om ärendet på grundfliken kan döljas med en feature flag, och utredningens felsökningspanel hålls borta i produktion.
Standup
Åtgärdsfliken som byggdes i går visades i testmiljön. Den som har flera roller väljer först vilken roll hen arbetar i; har man bara en behövs inget val. Rollen styr vilka åtgärdstyper som finns — enhetschefen har disciplinåtgärd, översyn, utbildningsinsats och övriga åtgärder, LEX-utredaren och MAS/MAR fler. LEX-utredaren och MAS/MAR kan inte registrera redan genomförda åtgärder, bara planerade, och de kommer in som förslag: det är enhetschefen som tar ställning till dem. Åtgärder som enhetschefen själv lägger till godkänns automatiskt. En genomförd åtgärd får ett datum bakåt i tiden, aldrig framåt, och en åtgärd kan aldrig vara både genomförd och förslag.
Var ska förslagen hanteras? Teamet har diskuterat internt om enhetschefen ska ta ställning till MAS/MAR:s och LEX-utredarens förslag under beslutsfliken eller i åtgärdsfliken. Förslaget är att allt som rör åtgärder hanteras i åtgärdsfliken — också att acceptera, förkasta eller omarbeta — annars hamnar åtgärderna huller om buller mellan utredning, beslut och åtgärder. Inget behövde beslutas i dag, men tanken togs väl emot. Från hälso- och sjukvårdshållet: det är enhetschefen som äger ärendet och arbetar mest med avvikelserna, så det är logiskt att allt ligger på ett ställe. Från LEX-hållet: en bra grundstruktur, men den behöver testas, eftersom flödena inte alltid är raka.
Ingen dubbeldokumentation. HSL-hållet frågade hur dubbeldokumentation undviks när händelseanalysen landar i åtgärder tillsammans med chefen. Svaret: alla roller arbetar i samma flik, och det syns vem som lagt varje åtgärd. LEX-hållet pekade på att mallen för Lex Sarah-utredningen innehåller förslag till åtgärder, som ges innan LEX-ansvarig fattar beslut — med åtgärdsfliken blir det två ställen. Behovet gäller utskriften: till IVO skickas både handlingsplanen och utredningen, och i utredningen ska det gå att se vilka åtgärder utredaren föreslog. Teamets svar var att utskriften kan hämta data från olika ställen i ärendet, så att ingenting behöver skrivas två gånger — frågan är vilka delar som ska med. Verksamheten tror inte att det blir ett problem, men kan behöva utmana sitt eget flöde.
Åtgärder går inte att ta bort. Den som skapat en åtgärd kan redigera den fram till att den är godkänd, men inte ta bort den. En felaktig åtgärd nekas i stället med en kommentar. Nackdelen är att en åtgärd som nekats för att den skapades av misstag inte går att skilja från en som nekats i sak när man tar ut statistik. Verksamheten tycker att det är bra att de inte går att ta bort: den som inte genomför en åtgärd måste förklara varför, och det ger ett lärande — både för chefen och för utredarna. Risken att skapa en åtgärd av misstag bedöms som låg, eftersom mycket ska fyllas i: vad som ska göras, när det ska starta och vara klart, och vilket resultat som förväntas. En åtgärd som inte längre är aktuell får en kommentar. Frågan tas ändå med enhetscheferna, som inte var med i dag.
Enhetschefens åtgärdstyper. Enhetschefen har bara fem typer på rubriknivå, vilket är få jämfört med utredarrollerna, och det är oklart om enhetscheferna hunnit gå igenom dem — det kontrolleras. Teamet avråder från Övrigt: det säger ingenting, och vid uppföljningen måste man då läsa varje sådan åtgärd för att förstå vad som gjordes. Samtidigt vet verksamheten att enhetschefernas åtgärder ofta är kreativa och inte passar i de typer som finns. Hellre då nya typer, gärna bredare men ändå sägande. För att få ett underlag undersöks om åtgärdstexter kan tas ut ur dagens system, så att teamet kan ta fram ett förslag på kategorisering utifrån ett större urval.
Fredag är det demo och retro, med sikte på att ta sig igenom avvikelseflödet. Verksamheten har inte kunnat testa, och det hinns inte den här veckan. I stället släpps testmiljön till verksamheten, så att de hinner testa inför sprint 2.
Beslut och öppna frågor
Öppen fråga: ska enhetschefen ta ställning till förslag i åtgärdsfliken? Teamet och verksamheten lutar åt att allt som rör åtgärder ligger där. Landas efter test. (ATG-04, UTR-06)
Öppen fråga: ska en egen åtgärd gå att ta bort innan den godkänts? I dag går den bara att redigera. Tas med enhetscheferna. (ATG-07)
Öppen fråga: hur förhåller sig utredningens förslag till åtgärder till åtgärdsfliken? Utskriften kan hämta från båda ställena; det som ska bestämmas är vad som följer med. (LEX-06, LEX-07, ATG-05)
Öppen fråga: räcker enhetschefens åtgärdstyper? Nya typer föredras framför Övrigt. (ATG-01)
Att göra: kontrollera med enhetscheferna om de gått igenom åtgärdstyperna.
Att göra: undersöka om åtgärdstexter kan tas ut ur dagens system som underlag för kategoriseringen. (ATG-01)
Att göra: släppa testmiljön till verksamheten inför sprint 2.
Levererat i kod
Åtgärdsfliken från gårdagens avstämning finns nu i koden, och behörigheten i utredningen hämtas numera från ärendelagret i stället för att räknas ut en gång till i Draken.
web-app-draken-public
- Åtgärdsfliken: åtgärdstyperna hämtas från ärendelagret och matchas mot användarens AD-grupper, med planering, redigering av egna åtgärder och ett eget beslutsflöde för chefen som bevarar förslagets innehåll och vem som lade det. Omarbeta räknas som delvis godkänt och kräver en kommentar. Skrivningar skyddas med rollkontroll och versionskontroll. (ATG-01, ATG-03, ATG-04, ATG-07)
- Ändrar två personer samma åtgärd samtidigt läses den om och utkastet sammanfogas: det den andra ändrat tas in, det man själv skrivit står kvar, och där båda ändrat samma fält pekas det ut i stället för att den ena tyst skrivs över. (ATG-07, HSL-08)
- Behörigheten för utredningsdokumenten kommer nu från ärendets eget åtkomstsvar i ärendelagret — det som byggdes i går — i stället för en egen konfiguration av AD-grupper per miljö. Reglerna finns därmed på ett ställe, och ett tvetydigt svar låser i stället för att öppna. (BEH-04, BEH-11)
- Utrednings- och beslutsflikarna visar dokumenten efter den åtkomst som faktiskt beviljats — dold, läsbar eller redigerbar — och kontrollerar den igen när ärendet ändras. En nekad läsning ger ett behörighetsfel i stället för att skicka användaren till inloggningen. (BEH-11)
- Beslutsdokumentet för Lex Sarah är på plats, med en beslutsflik som bara visas på ärenden som klassats som rapporterat missförhållande. (LEX-08, LEX-09)
- End-to-end-tester för dolda, läsbara och redigerbara dokument, dokumentation av åtkomstmodellen och ett antal rättningar för typkontroll och formatering.
api-service-support-management
- Mål, beskrivning och omarbetningskommentar på en åtgärd rymmer nu 3 000 tecken — målet var tidigare begränsat till 255. (ATG-02)
api-service-access-mapper
- Sökningen efter användare är omskriven, med rättning av typfiltret och justeringar efter granskning. (INT-04, BEH-12)
Standup
Sprint 1 närmar sig sitt slut, och dagens mål — liksom sprintens — var att ta sig igenom en avvikelse från rapport till avslut. Verksamheten har inte kunnat testa handläggningen särskilt mycket, bland annat för att en parallell sprint bygger funktioner i samma grund, och testandet väntas bli mer intensivt i sprint 2. I går gick åt till åtgärder, beslut och behörighet för att hela flödet ska fungera som tänkt, och till att få till den sista delen med IVO och PDF-export. Testanvändarna ska nu ligga i rätt grupper.
Missförhållanden som inte anmäls till IVO registreras inte i Public 360. Frågan hade legat öppen sedan en tidigare genomgång. Det är bara det som går till IVO som är utgående handlingar och ska dit; övriga missförhållanden och deras handlingar finns i Draken, där de går att spara och söka. Verksamheten instämde, så länge det går att spåra.
Enhetschefens åtgärdstyper. Verksamheten skulle gå igenom sina synpunkter samma förmiddag och skicka alla ändringar som en textfil i chatten; frågan om Övrigt tas med där. Verksamheten frågade också om skisserna är uppdaterade med de texter som redan ändrats, så att de inte ger synpunkter på något gammalt. Svaret: till största delen, och det som saknas — SoL/LSS-delen av utredningen — kompletteras under förmiddagen.
Demo
Demon följde en avvikelse genom hela kedjan. Texterna var inte på plats i testmiljön, och en del ser annorlunda ut än i skisserna där bygget krävt det.
Rapport och fördelning. Rapportören söker fram sin enhet — eller avdelning, där sådana finns — bland alla enheter inom VoF, och avvikelsen hamnar hos den enhetschef som har enheten. Fördelningen fungerar. Kvar står en fråga för framtiden: hur Draken får veta att organisationen förändrats, vilket inte är unikt för avvikelser. Ärendeuppgifterna visar exakt det som rapportören skickade in och redigeras aldrig — senare ändringar blir tillägg. (RAP-04, RAP-09, FLO-05)
Granskningsfasen ifrågasattes. Enhetschefen har inte mycket att göra i granskningen, och frågan kom om steget kan tas bort. Tanken var att chefen ska kunna konstatera att ärendet inte hör hemma hos hen, eller begära komplettering innan utredningen startar — men komplettering går att begära även under utredningen. Samtidigt vill verksamheten kunna stänga det som uppenbart inte är en avvikelse direkt, till exempel en arbetsmiljöavvikelse som registrerats fel och hör hemma i ett annat system, så att det inte ser ut som att allt gått till utredning. Hur många sådana ärenden som kommer in säger dessutom något om utbildningsbehovet. Fasen står kvar, och frågan om den behövs utvärderas. Teamet undersöker valbara avslutsorsaker, så att de ärendena kan räknas för sig. Tiden mäts redan per status, så det går att se hur länge ett ärende legat i varje steg. (FLO-01, FLO-02, MOD-08)
Utredning och rapport. I utredningsfasen öppnas flikarna Utredning och Åtgärder. Enhetschefen kategoriserar utifrån lagrum, fyller i mallen och gör riskbedömningen; utredningsmallarna är förberedda men inte alla inlagda. När utredningen markeras som klar kan en rapport skapas. Den blir en numrerad bilaga på ärendet som inte går att ta bort, eftersom handlingar ska sparas, och den kan laddas ned och skrivas ut. Rapporten är inget krav: utredaren kan också dela ett utkast med LEX-ansvarig för dialog, eller tilldela tillbaka. (UTR-01, KAT-04, LEX-07)
Åtgärder, beslut och uppföljning. Enhetschefen kan lägga till genomförda eller planerade åtgärder — rubriken heter inte längre omedelbar. Övriga rollers åtgärder är förslag, och ett förslag kan inte redan vara genomfört. Beskrivning och mål är obligatoriska, och handlingsplanen kan skapas som bilaga på ärendet. Den som inte lägger in några åtgärder måste bekräfta det och motivera varför. Bedömer enhetschefen att det är ett missförhållande kan fler roller lägga förslag, och chefen godkänner, nekar eller begär omarbetning — med motivering. I uppföljningen anges om en planerad åtgärd blev utförd och om den hade effekt. Verksamheten lyfte att det blir särskilt värdefullt vid chefsbyte: den som tar över ser vad som var planerat och varför. Alla åtgärder ska vara avslutade eller dokumenterade innan ärendet kan avslutas, och en samlad vy över planerade åtgärder i chefens alla ärenden ska göra det lätt att se vad som återstår. (ATG-02, ATG-04, ATG-05, ATG-06, UTR-06, UPF-06)
Till LEX och tillbaka. Sparar enhetschefen utredningen med misstänkt missförhållande kommer en varning om att ärendet ska lämnas till en LEX-ansvarig. När det är tilldelat ser chefen att ärendet finns och vilken status det har, men kan inte öppna det. Tilldelningen är bättre än i skissen: den listar de enhetschefer och verksamhetschefer som är aktuella för enheten, och när LEX lämnar tillbaka hämtas den chef som har platsen just då. Det löser ett känt problem i dag, att ärenden hamnar hos personer som inte längre är kvar. En enhetschef som är osäker kan tilldela sin verksamhetschef, som skickar vidare till LEX-ansvarig eller tillbaka. Verksamheten tycker att det blir tydligt och tvingar cheferna att ta ställning. Verksamhetscheferna kommer att vilja veta när en enhetschef skickar till LEX, men det kan räcka att de redan ser enhetens ärenden — teamet rådde att vara sparsam med notiser, eftersom de tappar värde när de blir för många. Enhetschefen kan också flytta ärendet till rätt plats om rapportören valt fel; ärendeuppgifterna behåller rapportörens val. HSL-flödet vid riskvärde 4 eller högre är inte aktiverat, och LEX-flödet är påbörjat och kommer i sprint 2. (FLO-07, FLO-09, LEX-10, BEH-07, NOT-01)
Synpunkter på gränssnittet. Verksamheten vill att ett klick på statusen i ärendelistan leder till fliken för det steg ärendet står i, till exempel uppföljningen — enkelt, och teamet höll med. Avslutsknappen i högerpanelen bryter mot flödet uppifrån och ned; Draken är byggd för att man ska kunna arbeta i valfri ordning, och en ny layout är planerad men inte möjlig att göra nu. Färgade knappar tar ärendet vidare, svarta sparar. Det finns ingen autosparning: man sparar själv, och webbläsaren varnar för osparade ändringar. Autosparning är svår med den teknik och de obligatoriska fält som används, och det tas med i utbildningsmaterialet. Den gamla åtgärdsrutan i slutet av flödet behövs sannolikt inte längre, nu när allt som rör åtgärder ligger i åtgärdsfliken.
Retro
Teamet beskrev två intensiva veckor, med en parallell sprint att synka med och mer som dykt upp än planerat. Från verksamheten kom två svårigheter: morgonmötena krockar med verksamheter som behöver chefen just på morgonen, och teamchatten är svår att hinna följa under dagen vid sidan av det vanliga arbetet. Svaret var att chatten finns för transparensens skull, så att ingenting bestäms i det tysta, och att alla inte behöver läsa allt — behövs svar från en viss person hör teamet av sig direkt, gärna per telefon.
Den andra lärdomen gällde att skisser och flera miljöer glidit isär, så att verksamheten ibland lämnat synpunkter på något inaktuellt. Framöver är det som byggs referensen och skisserna används för att stämma av, och teamet tar fram verktyg för att hålla dem i fas. Miljön verksamheten har tillgång till är en utvecklingsmiljö där saker ändras hela tiden, inte en miljö för acceptanstest.
Beslut och öppna frågor
Missförhållanden som inte anmäls till IVO registreras inte i Public 360. Handlingarna finns och är sökbara i Draken. (LEX-09, INT-07)
Öppen fråga: behövs granskningsfasen? Fasen står kvar och frågan utvärderas, tillsammans med hur ärenden som inte är avvikelser stängs tidigt och räknas för sig. Teamet undersöker valbara avslutsorsaker. (FLO-01, FLO-02)
Öppen fråga: enhetschefens åtgärdstyper, inklusive Övrigt. Verksamheten skickar sina ändringar. (ATG-01)
Öppen fråga: flyttas en planerad åtgärds datumintervall, eller anges när den genomfördes? (ATG-03)
Öppen fråga: ska ”inga åtgärder” leda direkt till redo för avslut? Enhetscheferna fattar i praktiken inga beslut i avvikelseärenden. (UTR-06, FLO-03)
Öppen fråga: behöver verksamhetschefen en notis när ett ärende skickas till LEX, eller räcker insynen i enhetens ärenden? (NOT-01, BEH-07)
Att göra: låta statusen i ärendelistan öppna fliken för ärendets steg. (UPF-05)
Att göra: släppa testmiljön till verksamheten nästa vecka, med testinstruktioner och de kända avvikelserna från skisserna dokumenterade.
Att göra: arbetsmöten om LEX-flödet inför sprint 2, preliminärt onsdag till fredag nästa vecka.
Levererat i kod
Sprintens sista dag knöt ihop flödet. Fasmodellen fungerar nu hela vägen, från att e-tjänsten skriver ärendet till att flikarna visas i rätt steg; ärendet kan lämnas till LEX och tillbaka, och utredningar, beslut och handlingsplaner blir bilagor på ärendet.
web-app-draken-public
- Två beslutsdokument ersätter ett: HSL-beslutet om IVO-anmälan för en vanlig HSL-avvikelse, och Lex Sarah-beslutet med LEX-ansvarigs klassning, obligatorisk motivering och utredarens förslag skrivskyddat från SoL/LSS-utredningen. Lex Sarah-beslutet kan inte sparas förrän utredningen är sparad. Ärendenumren för IVO och Public 360 finns bara när ärendet anmäls, och Public 360-numret är då obligatoriskt. Tidsstämplar och versioner sätts av servern och kan inte fyllas i. (LEX-08, LEX-09, HSL-06, MOD-05)
- Varje utredning avslutas med Är utredningen klar? Ett ja låser dokumentet, och det enda som då går att göra är att låsa upp det. Skapa rapport sparar och skapar en numrerad PDF som bilaga i samma klick; Förhandsgranska visar utkastet utan att bifoga det. Rapporten innehåller bara utredningens egna delar. (LEX-07, UTR-01)
- Handlingsplanen kan skapas som PDF och bifogas ärendet, och uppföljningen av åtgärder sparas. (ATG-05, ATG-06)
- Går man vidare till beslut utan åtgärder måste det bekräftas, och ett felplacerat ärende kan flyttas till rätt enhet. (UTR-06, FLO-09)
- Obligatoriska fält märks med (Obligatorisk) i stället för en asterisk, och fliken Åtgärder kommer före Beslut.
- Tester för båda besluten och rapportflödet, rättningar av formulär som felaktigt visade osparade ändringar, och justerade etiketter och filnamn.
web-app-draken-public
- Överlämning till LEX och tillbaka: ett ärende som klassas som missförhållande lämnas över till LEX-ansvarig, och vid återlämning tilldelas chefen för ärendets plats, hämtad ur behörighetstjänsten. Handläggarlistan filtreras per ärende — LEX-rollerna syns bara medan ärendet ligger hos LEX, cheferna annars. (FLO-07, LEX-10, FLO-05)
- Fasflödet läser nu ärendets aktiva fas rätt; tidigare kunde ingen fas markeras och ingen övergång erbjudas. Skrivningar prövas mot versionen av den resurs de ändrar. (FLO-01, FLO-03)
- Utrednings-, besluts- och åtgärdsflikarna erbjuds först när ärendet nått rätt fas — åtgärder från utredningsfasen, uppföljning i beslutsfasen. (BEH-11, FLO-03)
- Starta handläggning flyttar ärendet ur registreringsfasen och låter fasen sätta statusen, efter en rad rättningar under dagen. (FLO-01)
- Knappen för att återlämna utredningen till chefen ligger nu vid spara-knappen, och ett demoläge med banner kan slås på per användare. (LEX-10)
web-app-katla-sm
- Ärendets fas sätts vid varje skrivning från e-tjänsten, även när ett utkast skickas in — tidigare stod inskickade ärenden utan steg i handläggningsprocessen. (FLO-01)
web-app-katla-sm
- Varje skrivning av ett ärende kräver giltiga platsuppgifter. (RAP-04, MOD-06)
Läget
Mellan sprintarna hålls inga standuper, så kortet bygger bara på koden. Den första veckan gick åt till att slutföra det demon 11 september visade och att få in sprintens backend i main. Sedan dess har arbetet i ärendelagret fortsatt på en egen gren för sprint 2.
Ärendelagrets del av sprint 1 ligger på main. Sprintgrenen mergades 17 september med grönt i tester, CodeQL och Sonar. Draken-webbens del ligger kvar på sprintgrenen. Dess pull request mot develop har konflikter, och testerna som kördes 18 september föll, både e2e för IAF och VoF och enhetstesterna. Rader som kräver både backend och gränssnitt står därför kvar som pågår.
Levererat i kod
web-app-draken-public
- Fasmodellen styr statusarna. Statusväljaren visar bara det den aktiva fasen tillåter, och en processknapp i sidopanelen tar ärendet vidare. Ärendet öppnas på den aktiva fasens flik, och den sista fasen avslutas med Avsluta ärendet. Ärenden i granskning, beslut och uppföljning räknas nu som öppna. (FLO-01, FLO-03)
- Ett ärende kan inte avslutas medan någon åtgärd väntar, till exempel ett förslag som ingen beslutat om eller en planerad åtgärd som inte följts upp. Spärren sitter på skrivningen, inte bara på knappen. (FLO-10, ATG-04)
- Uppföljningen sparas direkt på åtgärden, med resultat och datum. (ATG-06)
- Tilldelningen till LEX kan skjutas upp men måste vara gjord före beslut. En varning ovanför flikarna säger när ett missförhållande skickas vidare automatiskt. Beslutsfliken säger vem som fattar beslutet när man inte gör det själv. Överlämning och återlämning sätter ärendet som tilldelat. (FLO-02, FLO-07, FLO-12, LEX-10)
- Enhetschefen kategoriserar per lagrumsgrupp, med en väljare för HSL och en för SoL/LSS. SoL/LSS-utredningen visar bara sin egen väljare. (KAT-04, KAT-05)
- Ofullständiga utredningar kan sparas som utkast. Kraven gäller först när utredningen markeras som klar, och då i formulär, BFF och ärendelager. (UTR-01, UTR-05)
- Enhetschefen registrerar ärendet i Draken genom att först ange vad som hänt, var och med vilken prioritet. Ärendet skapas ur de valen. Handläggarrollerna är samlade i en katalog med en AD-grupp per roll. (BEH-01, BEH-08)
- Meddelanden via Katla kan bära bilagor, och de kan skickas först när ärendet lämnat första fasen. Ärendena har fått tjänsteanteckningar, och demoläget är borttaget. (RAP-10)
- Obligatoriska fält markeras inte längre som fel innan man har försökt spara.
web-app-draken-public
- En samlad vy visar planerade åtgärder i alla ärenden man når, i facken Försenade, Kommande två veckor och Senare. Förslag visas inte, och uppföljningen görs i ärendet. (UPF-06)
- Utkast bevaras och ärendeversioner skyddas vid samtidiga skrivningar. Develop mergades in i sprintgrenen 17 september. (HSL-08)
api-service-support-management
- Faser och åtgärder kan begränsas som andra fält. Tidigare föll de tyst bort för alla med begränsad åtkomst. (BEH-11)
- En ändring binds till de fält avsändaren har rätt till. Annars avvisas den helt, i stället för att tas emot till hälften. (BEH-11, HSL-02)
- En regel kan begränsas till vissa operationer, så att eskaleringen till LEX inte körs igen när en utredare lämnar tillbaka ärendet. (FLO-07, LEX-10)
- En åtgärdstyp kan höra till flera grupper, men måste höra till minst en, och mål och beskrivning rymmer 3 000 tecken. (ATG-02, ATG-08)
- Sökning i ärenden, på grenen för sprint 2. Den söker i fritext över ärendet och allt som hänger på det. Den når bara det användaren har rätt till, och fält man inte får läsa söks inte heller, eftersom en träff annars skulle avslöja vad de innehåller. Indexet byggs om från databasen varje natt. Sökningen mergades till sprint 2-grenen 29 september med grön CI.
api-service-support-management
- Åtgärden fick versionskontroll som de andra handläggningsdokumenten. Den som skriver tillbaka något inaktuellt får nej i stället för att skriva över. (HSL-08)
- Parametrar och bilagor hålls per dokument i stället för på ärendet, och utfallen av beslut registreras per namnrymd. (BEH-02)
api-service-support-management
- Flytt av labels kräver ett uttryckligt val mellan provkörning och skarp flytt. Flytten räknar berörda ärenden även under labeln, och den startar inte om en flytt redan väntar. (MOD-06)
api-service-support-management
- E-post som notiskanal, i en pull request mot sprint 2-grenen som väntar på granskning. (NOT-01)
api-service-access-loader
- Loadern mergades till main 15 september med grön CI, med en IAF-konfiguration och avgränsning till givna organisationer. (INT-04)
web-app-katla-sm
- Meddelandets text valideras först när man har försökt skicka. (RAP-10)
Avgjort sedan sprint 1
IVO-anmälan och ärendenumret dokumenteras i beslutsfasen. Public 360-numret krävs när ärendet anmäls, och IVO-numret är frivilligt. Det är byggt i både HSL- och LEX-flödet. Frågan stod öppen dag 7. Källa: teamschatten 10 september. (MOD-05, LEX-09)
Verksamheten har skickat in nya åtgärdstyper och orsaksområden för enhetschefen, vilket svarar på frågan från dag 9 och 10. Källa: textändringar för enhetschefsvyn, 11 september. (UTR-06, KAT-08)
Enhetschefens utredningsmallar är framtagna, en för SoL/LSS och en med HSL, på workshopen 7 september. De är inte inlagda än. Källa: mallarna i teamschatten, 7 september. (UTR-01)
Rapportören ligger kvar först i rapporteringen, och texten vid rapportering åt en kollega behålls. Källa: verksamhetens testunderlag för rapporteringen, 1 september. (RAP-01, RAP-06)
Öppet inför sprint 2
När lösningen ska driftsättas är inte bestämt. Teamet behöver svaret för att planera sprint 2. Styrgruppens beslut gällde utbildningen: enhetscheferna ska få utbildning i analys, åtgärder och effekter, inte bara i hur systemet används, i samband med Lifecare-utbildningen. Utrullning och utbildning stäms av med verksamheten. Källa: teamschatten 22 september. (fråga #36)
Sprintplanering
Sprint 2 började med en planering vid tavlan. Fjorton krav lades upp och fördelades på sprintens två veckor och på det som behöver tas efter sprinten. Det som påbörjas första veckan och görs klart under den andra står i båda.
Vecka 1
MAS/MAR-flödet — den del av HSL-flödet som MAS/MAR äger. (HSL-01–HSL-09)
Test av enhetschefens flöde och Lex Sarah-flödet tillsammans med verksamheten.
Påbörjas vecka 1, klart vecka 2
Mobil som PWA — systemet ska kunna nås via en länk i lösningen för delade mobiler.
Gränssnittet uppdateras utifrån den nya metoden att söka data.
Påbörjas vecka 1, fortsätter efter sprinten
Notifiering — både funktionen och logiken för när notiser skickas. (NOT-01–NOT-05)
Säkerhet — loggar, säkra anrop och krypterad databas.
Vecka 2
Verksamhetsuppföljning — att söka data. (UPF)
AccessLoader — hantering av platser och av organisationsförändringar. (INT-03, INT-04)
Loggen på ärendet blir bättre där den visas i gränssnittet.
Efter sprinten
Utöver notifiering och säkerhet tas fyra krav efter sprint 2: admin-gränssnittet, som är nytt och inte prioriterat, prodsättningen med merge till main och härdning av lösningen i produktion, utrullningen i verksamheten och Avvikelse i vårdkedjan. (fråga #25)
Levererat i kod
web-app-draken-public
- Översiktens lista och räknare kan svara från ärendelagrets nya sökindex. Det är avstängt som standard, eftersom indexet måste byggas om innan det innehåller äldre ärenden. När indexet inte kan svara likadant används det vanliga filtret.
- Sidomenyns räknare hämtas i ett anrop i stället för fem.
- Texterna i Åtgärder och Uppföljning följer verksamhetens textändringar. Valet heter Planerade åtgärder och Genomförda åtgärder, med planerade först, målfältet heter Beskriv syftet med åtgärden, och uppföljningens hjälptext säger att alla åtgärder måste vara utförda innan ärendet kan avslutas. (UTR-06, ATG-02)
- Orsaksområdet för rutiner heter nu Processer, rutiner, arbetssätt, riktlinjer i enhetschefens och SoL/LSS-utredningen. Ändringen ligger i nya schemaversioner i testmiljön, och sparade utredningar påverkas inte. (KAT-08, UTR-02)
- Valet av utredningsmall fyller nu i utredningstexten med verksamhetens mallar för SoL/LSS och för SoL/LSS med HSL. Har chefen redan skrivit något frågar formuläret först. Mallarna ligger i testmiljön. (UTR-01)
- Ett ärende går till Beslut först när utredningen är sparad som klar — LEX-utredningen vid missförhållande, annars enhetschefens. Fasknappen säger vilken utredning som saknas, och regeln gäller även i backend. (FLO-12, LEX-08)
- Enhetschefen kan registrera en avvikelse direkt i Draken, med plats från sin anställning. Registreringssidan är uppbyggd som i CaseData och frågar inte längre efter prioritet, och chefen fyller i rapporten tills ärendet når Utredning. (RAP-01, FLO-05)
- Utredningarna sparas med Spara ärende i sidomenyn i stället för med egna knappar. Ett dokument som inte kan sparas pekas ut med flik och orsak.
- Tider visas och sparas i samma format som i Katla, registreringsvalen läses rätt mot den riktiga backenden, och versionshanteringen efter sparning har flyttats till en egen hook.
api-service-support-management
- E-post som notiskanal är mergad till sprint 2-grenen, med en egen händelsetyp för ärenden med begränsad åtkomst. (NOT-01)
api-service-support-management
- Loggningen har begränsats. Pull requesten mot sprint 2-grenen har grön CI och väntar på granskning.
Standup
Sprinten ska landa. Vecka 1 går ut på att låsa enhetschefens flöde med de justeringar som gjorts, få LEX-flödet och händelseanalysen helt färdiga och få säkerhet och behörigheter på plats. Projektet räknar den tekniska förberedelsesprinten som sprint 1, så i projektets numrering är det här sprint 3.
Enhetschefens flöde demonstrerades från början till slut för verksamheten. Rapporteringen visar nu bara brukarens namn, inte adressen, för att inte exponera onödiga uppgifter. Ärendet hamnar automatiskt hos enhetschefen för platsen. Kommentarer är arbetsanteckningar, medan tjänsteanteckningar finns kvar på ärendet efter avslut och låses upp när handläggningen inleds. Komplettering begärs med ett meddelande till rapportören via Katla, och svaret syns som en tråd på ärendet. Utredningen börjar med lagrum och avvikelsetyp, mallen fyller i texten, vid HSL är konsultation med legitimerad personal obligatorisk, och utredningen måste markeras klar innan ärendet går vidare. Åtgärderna dokumenteras som planerade eller genomförda och följs upp med effekt, och avslutsknappen tänds först när alla åtgärder är klara.
Beslut
Ett ärende som väntar på komplettering låses inte. Enhetschefen kan återuppta det när som helst, oavsett om kompletteringen har kommit. Verksamheten bekräftade att det är så det ska fungera. (FLO-02, FLO-04)
Två klassificeringar: en för SoL/LSS tillsammans och en för HSL. (KAT-05, KAT-06, fråga #27)
Frågan i åtgärdsuppföljningen ska handla om effekten. ”Vad har hänt?” riskerar att leda tillbaka till händelsen. Verksamheten föreslog ”Beskriv effekten”, eller ”Beskriv den önskade eller uteblivna effekten”. (ATG-06, fråga #40)
Meddelanden går till den som skickade in rapporten. Har den rapporterat åt en kollega får enhetschefen ta kontakten på annat sätt. E-postnotisen säger bara att det finns ett meddelande, utan innehåll, så inget sekretessbelagt hamnar i en privat inkorg. (NOT-05, fråga #28)
Att göra
- Knappen för att parkera ärendet ska döljas — det är beslutat sedan tidigare men inte gjort.
- Lex Sarah-fliken ska bara synas för den som har rollen, och Händelseanalys HSL bara vid HSL-riskvärde 4 eller högre. (LEX-01, HSL-01, HSL-02)
- Innehållet i rapporten som skapas från utredningen är inte genomgånget. (LEX-07)
- Profiler för prenumerationer på notiser ska utredas. (NOT-04, HSL-10)
- Verksamheten skriver textsynpunkter direkt i chatten, och teamet samlar dem till en ändring. Texterna gås igenom med enhetscheferna under dagen.
- Lex Sarah-flödet testas tillsammans med verksamheten torsdag 8 oktober. (teamschatten)
Levererat i kod
web-app-draken-public
- Översikten har fått en sektion för verksamhetsuppföljning med flikarna Ärenden och Åtgärder, för de enheter användaren når. Filtren följer skissen, och tabellerna går att sortera. (UPF-04, UPF-05, UPF-06, UPF-10)
- Verksamhetsuppföljningen har fem lägeskort över periodens ärenden. Kortet för ärenden som stått som Ny i mer än 30 dagar blir orange när det finns några. Enhetsfiltret visas bara när ärendena ligger på mer än en enhet, och menyknappen heter efter rollen: Enhet, Enheter eller Verksamhetsområde. (UPF-01, UPF-02, UPF-03)
- Ett ärende märks med Hög risk HSL när enhetschefens utredning klarmarkeras med ett HSL-riskvärde på 4 eller högre. Märkningen tas bort om värdet sänks under 4. (HSL-01)
- Medan LEX har ärendet har enhetschefen och verksamhetschefen bara läsrätt. Ärendet låses då för dem, och översikten visar LEX som ansvarig. (FLO-12)
- Åtgärdsuppföljningen frågar ”Beskriv åtgärdens effekt”, enligt beslutet på standupen. (ATG-06, fråga #40)
- Fasövergångarna heter Inled utredning, Redo för beslut och Inled uppföljning. (FLO-01)
- Katla är förvald när ett e-tjänstärende besvaras, och Redigerbar eller Skrivskyddad visas på utredningen även i produktion.
web-app-katla-sm
- Katla går att installera som app på mobilen. Sidor och svar sparas aldrig i telefonen, och utan nät visas en offlinesida. Pull requesten har grön CI och väntar på granskning.
api-service-support-management
- Fortsatt arbete med att begränsa loggningen. Pull requesten väntar på granskning.
Standup
Notiser. Backendutvecklarna har ritat upp hur notiserna ska fungera, och kodningen har börjat. Alla användare läses in på en gång, så att den som till exempel blir tilldelad som chef får e-post direkt, utan att någon behöver administrera det. Troligen blir det en notisprofil per roll. Profilerna blir ganska lika, men de kan justeras centralt. (NOT-01, NOT-04)
Övrigt i backend. Arbetet med att begränsa loggningen är nästan klart och skickas på granskning i dag. Därutöver har det handlat om små justeringar av behörigheter och konfiguration, och om nya labels och kategorier, bland annat den label som märker ärenden med HSL-riskvärde 4 eller högre. (HSL-01)
LEX-flödet och tester. I går testades enhetschefens flöde, och testerna av Lex Sarah-flödet påbörjades. En mall för hur Lex Sarah-utredningen ska se ut, byggd på verksamhetens underlag, ligger nu i teamets kanal. Testerna av Lex Sarah-flödet fortsätter, och i morgon testas det tillsammans med verksamheten. Flödet bedöms vara nära klart.
Utrullning och utbildning
Verksamheten inom VoF lyfter frågan om utrullning vidare mot styrgruppen den här veckan, och det finns en hel del att ta ställning till. IAF är inte med i det resonemanget ännu, och teamet tar upp diskussionen med IAF:s representanter, så att båda förvaltningarna kan få en mjuk start. (fråga #36)
Teamets erfarenhet är att det är bäst att börja med en liten grupp. Då kan både lösningen och utbildningen justeras innan alla börjar använda den. Hur och när lösningen rullas ut påverkar hur mycket arbete som läggs efter sprinten för att få den helt produktionsklar, och tidpunkten hänger ihop med införandet av Lifecare.
Verksamheten lyfte också andra beroenden. Delade telefoner behövs för att personal i hemtjänst och på boenden ska kunna logga in på ett rimligt sätt. Ansvaret ligger hos välfärdstekniken, VoF siktar på årsskiftet och IAF har ingen plan ännu. Dessutom finns frågan om parallella system för synpunkter, klagomål och avvikelser i vårdkedjan. Avvikelse i vårdkedjan ingick inte i beställningen, men teamet har mött de berörda och skissat ett flöde som kan passa in. (fråga #25, fråga #41)
Att göra
- Stämma av status för de delade telefonerna. (fråga #41)
- Starta resonemanget om utrullning med IAF:s representanter, och träffas sedan om just den frågan för att få samsyn. (fråga #36)
- Testa flödet med ytterligare en representant från verksamheten i dag, och hitta en annan tid för den som inte kan vara med på morgondagens test.
Levererat i kod
web-app-draken-public
- Lex Sarah-utredningen följer verksamhetens utredningsmall: Bakgrund, Vad har hänt?, Varför har det hänt?, Förslag till beslut, Kategorisering och Avsluta utredning. Bakgrunden fylls i av Draken och är låst, och varje Nej ska motiveras. Sparade utredningar ligger kvar på den tidigare versionen. (LEX-03, LEX-04, LEX-05)
- LEX-ansvarig gör en initial bedömning av om ärendet ska anmälas till IVO och om det ska lex-utredas. Ska det inte utredas går ärendet tillbaka till chefen som en avvikelse, med motiveringen som tjänsteanteckning. LEX-utredaren skickar inte ärendet till beslut utan tilldelar det en LEX-ansvarig. (LEX-08, LEX-09)
- När enhetschefens utredning är klarmarkerad med misstänkt missförhållande kan ärendet lämnas över till en LEX-ansvarig direkt i handläggarlistan. MAS/MAR får en egen väljare under Ansvarig, och Mina ärenden visar även ärendena där de står som MAS/MAR. (FLO-12, HSL-10)
- Märkningen Hög risk HSL sätts vid varje sparning av utredningen med riskvärde 4 eller mer och ligger sedan kvar, så att MAS/MAR inte tappar ärendet. Cheferna ser Händelseanalys HSL först när ärendet har märkningen. (HSL-01, HSL-02)
- Enhetschefen och verksamhetschefen klarmarkerar godkända åtgärder, oavsett vem som föreslog dem. (ATG-04)
- Kommentarer och tjänsteanteckningar visar vem som skrev dem, ett avslutat ärende stänger sin flik, och verksamhetschefen syns i Ansvarig-listan igen.
api-service-support-management
- Ärendelagrets sprint 2-gren är mergad till main med grön CI. Den innehåller sökningen över ett sökindex, räknare för sökningar och e-post till den som prenumererar på ett ärende. (INT-01, NOT-01)
- Sökningen har härdats. Den tolkar frågor på samma sätt som sökmotorn och söker bara i fält användaren får läsa, och ett datum i en sökning räknas som ett dygn i svensk tid.
- Den som skriver ett meddelande får ingen notis om sitt eget meddelande.
api-service-support-management
- Prenumerationsprofiler styr vilka händelser som går till vilka kanaler, så att en roll kan få en fast uppsättning notiser. Medlemmarna i en profil kan synkas av ett jobb, och den som själv lämnat en profil läggs inte tillbaka. (NOT-04)
- Tilldelning blir en egen händelse, och en notis kan villkoras på att en viss label läggs till. Det gör att MAS/MAR kan få e-post när ärendet märks med hög HSL-risk. (NOT-01, NOT-02)
- Rapportören prenumererar automatiskt på sitt nya ärende med en egen profil. (NOT-05)
web-app-katla-sm
- Katla har fått en steg-för-steg-guide för att rapportera en avvikelse, med en hjälplänk på varje sida. Bilderna tas automatiskt ur det riktiga flödet med påhittade uppgifter, så att guiden följer med när en text ändras. Pull requesten väntar på granskning.
Standup
Första veckan av sprinten närmar sig slutet. Notiserna fortsätter, och en pull request är på väg. Ärendelagrets kod, som flera drakar delar, är nu uppdaterad till senaste versionen i alla spår. Det förbereder också för utrullningen.
Lex Sarah-flödet var i fokus i går, med mallarna och tester. I eftermiddag testas hela flödet med verksamheten, med fyra olika identiteter. HSL-flödet testas med MAS/MAR tisdag 13 oktober. Dialogen om att föra ut lösningen till mobiler har startat. Första testet görs på en vanlig arbetsmobil, eftersom det ska vara samma tekniska väg som för de delade mobilerna. (fråga #41)
Första versionen av verksamhetsuppföljningen är klar att visa. Behoven skiljer sig mellan rollerna medan funktionen är densamma, så alla som vill ska få tycka till. (UPF-01–UPF-06)
Hur många ärenden en enhetschef har samtidigt beror på hur chefen arbetar och hur stor enheten är. Ett tiotal ohanterade ärenden är inte ovanligt i dag, och vissa chefer har många fler. En tydlig överblick över vad som pågår och vad som måste göras kan bli en drivkraft för att arbeta systematiskt. (UPF-02, UPF-03)
Beslut
Enhetschefens flöde för avvikelser låses som version 1.0. Teamet lägger inte mer tid på att justera det nu, utan på LEX-flödena, verksamhetsuppföljningen och tekniken under huven. Textändringar går alltid att göra. De texter som återstår är nyanser som inte ändrar flödet, till exempel att de blå knapparna ska heta Inled uppföljning i stället för Skicka till uppföljning. Det verksamheten ser i testmiljön nu är det de får.
Testmiljön är sanningen. AI-skissen ligger efter testmiljön, och det är testmiljön som gäller vid granskning.
Teamet uppmanade också till att inte ta med något från det gamla systemet bara för att det känns bekant, utan att plocka det som är bra och tänka nytt.
Att göra
- Verksamheten har svårt att veta vilka av deras inskickade textändringar som är gjorda. Teamet bokar en genomgång med dem som skrev dokumenten, och stämmer av vad som är infört och varför något inte är det. (fråga #42)
- Verksamheten testar avvikelseflödet för enhetschefen nu och skriver det som är otydligt direkt i chatten.
- En demo av verksamhetsuppföljningen, troligen fredag 9 oktober, och en egen tid för dem som inte kan vara med.
Testrunda av Lex Sarah-flödet
På eftermiddagen testade verksamheten och teamet missförhållandeflödet med var sin roll, från rapporten i Katla till avslutat ärende. Flödet höll hela vägen. De flesta fynden var buggar och obligatoriska fält som ska justeras. Version 1.0 blir i stort det som visades, och större gränssnittsförändringar ryms inte utan att något annat prioriteras bort.
Beslutade ändringar — buggarna rättas och ändringarna genomförs:
- Ärendesidan visar inte ”(Ärendetyp saknas)” förrän ärendet har en klassificering.
- Lagrum sätts inte automatiskt för missförhållanden, utan anges av LEX-utredaren. (LEX-03)
- Motiveringen i beslutet SoL/LSS ska vara obligatorisk. Bugg. (LEX-08)
- Enhetschefen ska inte kunna avsluta ett missförhållande. Bugg. (FLO-12)
- En saknad obligatorisk klassificering ska ge en varning. Bugg.
- Startdatum på en åtgärd ska inte gå att ändra i uppföljningen, slutdatum ska gå. Bugg. (ATG-03)
- Frågan om IVO-anmälan tas bort ur LEX-utredarens förslag till beslut. (LEX-05)
- Missförhållanden får samma utredningsmall för SoL/LSS som avvikelser. (UTR-01)
- Inled uppföljning döljs för LEX-ansvarig och LEX-utredare, eftersom uppföljningen är chefens.
Att utreda — teamet återkommer med vad de kostar i tid:
- Kan riskmatrisen SoL/LSS döljas i enhetschefens utredning när ärendet är ett missförhållande?
- Kan datum på åtgärder vara frivilliga för LEX-utredaren men obligatoriska för enhetschefen? (fråga #44)
- Varför ersattes knappen Tilldela av väljaren Ansvarig för LEX-ansvarig?
- Kan man hamna på rätt flik när ärendet återupptas?
- Kan LEX-utredaren återlämna till chef utan att först återuppta ärendet?
- Kan Utredning Lex Sarah få ett fritt fält där utredaren sammanfattar vad rapporten gäller?
- Kan enskilda fält uteslutas från den utskrivna rapporten?
- Kan kopplingen mellan Utredning Lex Sarah och fliken Åtgärder bli tydligare?
- Kan Ja/Nej-frågorna få alternativet ”Ej aktuellt”?
Önskemål som inte beslutades går till LEX-gruppens förbättringslista: söka fram ärenden där rapportören angav missförhållande men chefen svarade nej, statistik per verksamhet i stället för per lagrum, handlingsplanen som eget dokument, dölja ärendestatus och prioritet, färre förekomster av ordet ”avvikelse” i missförhållandeärenden, förprogrammerade fraser i textfälten och mindre information på en gång när ett ärende öppnas första gången.
Bekräftat i testet var bland annat att ett missförhållande som enhetschefen inte hanterat inom sju dagar tilldelas LEX-ansvarig automatiskt, att utredningsstarten registreras när LEX-utredaren startar, att Utredning Lex Sarah är dold för enhetschefen tills en rapport skapas, och att chefen ser sina godkända åtgärder som en lista efter datum, med försenade åtgärder markerade.
Arbetssätt, inte systemändringar. Handlingsplanen ägs av verksamheten: LEX-utredaren föreslår, och enhetschefen beslutar och dokumenterar. Tills datumfrågan är löst kan utredaren skriva åtgärdsförslagen i utredningstexten och låta enhetschefen registrera dem. Ingen ska använda systemet utan utbildning, och systemet ska testas av enhetschefer som inte varit med i arbetet.
Planering. Teamet har den här veckan och nästa avsatta, och därefter en svans för tekniska rättningar. Akuta brister rättas nu, och större ändringar i Draken planeras separat. Krävs större gränssnittsförändringar kan Avvikelse i vårdkedjan och mer verksamhetsuppföljning prioriteras bort. Synpunkter och klagomål ligger kvar i nuvarande system, och frågan om att beställa till den delen är ställd. (fråga #25, fråga #36)
Från teamschatten
Verksamheten föreslog att filterfältet på enhetschefens startsida ska vara dolt som standard. Det är tekniskt enkelt, men åsikterna går isär, så frågan gick till omröstning i chatten. (fråga #43)
Levererat i kod
web-app-draken-public
- LEX tar inte ärendet till uppföljning. En handläggare med bara LEX-roller får i stället beskedet att återlämna ärendet till chefen, och regeln gäller även i backend. Det var en av de beslutade ändringarna från testrundan.
- Ärendet avslutas först när åtgärderna är uppföljda, och det som saknas står under avslutsknappen. (ATG-06)
- LEX-utredaren lämnar ärendet till den LEX-ansvarige som gav hen det, i stället för till den första i listan.
- Utredningen stannar där handläggaren är när den sparas, i stället för att hoppa till toppen av formuläret. En sparning efter Återuppta ärende nekas inte längre som någon annans ändring.
- Testsviterna för VoF är gröna igen. Tre av de röda testerna pekade på riktiga fel, och de är rättade.
api-service-support-management
- Prenumerationsprofilerna är justerade efter granskning. Handläggaren och rapportören prenumereras var för sig, så att ett fel för den ena inte stoppar den andra, och en profil kan inte tömmas på filter eller kanaler. Pull requesten väntar på granskning. (NOT-04, NOT-05)
Standup
Gårdagens testrunda av Lex Sarah-flödet uppfattades som mycket givande, och verksamheten testar vidare tillsammans med teamet i dag. Fokus i dag är att rätta det som testrundan hittade i Lex Sarah-flödet, att testa notiserna tekniskt och att analysera vad Avvikelse i vårdkedjan skulle kräva tekniskt. (fråga #25)
Notiser. Gränssnittet följer nu ärendelagrets nya prenumerationsmodell, och backendens pull request för prenumerationsprofilerna har gett en del diskussion. Nästa steg är jobbet som lägger till cheferna som prenumeranter utifrån deras grupp. Teamet har landat i en design där notiserna är konfigurerbara, så att de kan styras och ändras när nya funktioner och krav kommer. Modellen har stöd för notiser i appen, e-post och sms och kan byggas ut med fler kanaler. För sms behövs ett säkert telefonnummer, och tanken är att använda det nummer användaren själv har angett. Varje roll får en grundprofil, och användaren ska själv kunna välja till exempel e-post eller sms. (NOT-01, NOT-04)
Statistik. Draken är inte gjord för analyser, och det kommer inte att byggas där. Verksamhetsuppföljningen i Draken ger enkel statistik direkt, och dess data kan sedan användas i kommunens analysverktyg. Teamet bjuder in till ett arbetsmöte om verksamhetsuppföljningen som första steg. (UPF-01–UPF-12)
Utskrift och utlämnande. Verksamheten behöver varje vecka kunna ta ut förra veckans inrapporterade ärenden, med händelsebeskrivningen, när media begär ut dem. Cheferna behöver också kunna lämna ut uppgifter när någon begär det enligt GDPR. Utskrift behövs alltså i alla steg. Det finns en första ansats för att exportera ärendelistan, skriva ut delar av ett ärende och exportera från verksamhetsuppföljningen, men exporten är inte aktiverad ännu. (UPF-09, fråga #45)
Att göra
- Verksamheten och UX-designern går igenom gränssnittet måndag eller tisdag, om ändringar ska hinna med i sprinten. Det som inte hinns med kan tas senare.
- Teamet jämför verksamhetens inskickade textdokument med det som är gjort. Uppenbart missade ändringar rättas direkt, och det som är oklart tas på ett möte, gärna samma som UX-genomgången. (fråga #42)
- Kallelse till ett arbetsmöte om verksamhetsuppföljning och statistik kommer mitt i nästa vecka.
- Teamet visar exportfunktionerna och tar reda på vad som behöver läggas till för utlämnande. (fråga #45)
Frågor och feedback från verksamheten
Här samlas frågor och synpunkter som kommer in när verksamheten testar leveranserna, med ett löpande nummer och en kort kommentar om läget. De fullständiga svaren finns i Verksamhetsfeedback och frågor på Confluence.
Har du inte tillgång till Confluence, ställ frågan i teamskanalen i stället.
-
#1 Får vi rapporter i Qlik Sense under sprintarna? Hanterad — nej, det arbetet hänvisas till BI-teamet. Se UPF-02 och UPF-11.
-
#2 Kommer AI-understödd analys av fritext att ingå? Hanterad — nej, den ligger utanför sprintarna. Se UPF-08.
-
#3 Vilka informationssäkerhetsåtgärder kräver klass 3-data av sprinten? Under utredning — frågan tas upp i riskanalysen för informationssäkerhet, som började 14 september, och informationsägarna beslutar. Frågan om vilken katalog personnummer får sökas mot hänger ihop med den. Källa: teamschatten 1 och 7 september.
-
#4 Ska platsen förväljas utifrån rapportörens anställning? Hanterad — nej, platsen väljs alltid aktivt. Se RAP-04.
-
#5 Vad händer med en påbörjad registrering om fönstret stängs? Hanterad — en varning är byggd. Se RAP-01.
-
#6 Vad tillför knappen Skicka in och logga ut? Hanterad — knappen är borttagen. Se RAP-01.
-
#7 Hur visar formuläret vad som saknas när rapporten skickas in? Hanterad — en samlad felsammanfattning är byggd, och mönstret ska vara detsamma i alla drakar. Se RAP-01.
-
#8 Måste alla rapporter ha ett personnummer på brukaren? Under utredning — personnummer behålls, och sökningen mot katalogen står kvar tills informationsägarna beslutat i riskanalysen. På sikt kan sökningen gå mot Lifecare i stället. Se RAP-03. Källa: teamschatten 1 och 7 september.
-
#9 Vad är Redigera uppgifter under rapportören, och hör den dit? Hanterad — möjligheten att redigera e-post och telefon tas bort. Se RAP-06.
-
#10 Varför behövs anställningsform, och finns den inte i personaldatan? Hanterad — uppgiften gick att härleda ur anställningen, så formen sätts automatiskt. Valet i formuläret är borttaget. Se RAP-11.
-
#11 Ska rapportören eller typen av rapport visas först i formuläret? Hanterad — rapportören först, därefter typ av rapport. Se RAP-01.
-
#12 IAF har avdelningar som inte finns i listan — hur fylls den på? Under utredning — arbetsplatserna finns inte i organisationsträdet och underhålls manuellt. Se INT-03.
-
#13 När chefen själv är rapportör — vem får ärendet? Hanterad — ingen automatik byggs. Enhetschefen tilldelar manuellt vidare om ärendet ska till verksamhetschefen. Se BEH-01.
-
#14 Vem räknas som rapportör när man rapporterar åt en kollega? Hanterad — kollegan man rapporterar åt, inte den som satt vid tangentbordet. Se RAP-06.
-
#15 Flera hjälptexter och rubriker är för svåra — kan de göras enklare? Under utredning — eget möte med UX bokat utanför standupen. UX äger avgörandet om ordval.
-
#16 Fungerar upplägget för vikarier, som ofta saknar kontaktuppgifter? Under utredning — anställningsformen härleds nu automatiskt, men saknas kontaktuppgifter får enhetschefen ta reda på vem som ska kontaktas. Se RAP-11 och RAP-06.
-
#17 Kan hjälptexterna under rubrikerna tas bort? Hanterad — nej, de står kvar och visas direkt. Verksamheten gav med sig vid avstämningen 4 september. Se RAP-01.
-
#18 Kan texten som visas när man rapporterar åt en kollega tas bort? Hanterad — texten behålls utifrån UX-principer. Se RAP-06. Källa: verksamhetens testunderlag för rapporteringen, 1 september.
-
#19 Ska knappen heta lägg till rapportör, och telefonnumret märkas ej privat? Hanterad — båda är åtgärdade. Se RAP-06 och RAP-11.
-
#20 Ska informationstexten under typ av rapport visas först när man valt? Hanterad — nej, texten visas direkt så att alternativen går att jämföra innan valet görs. Se RAP-01.
-
#21 Ska det stå rapporten i stället för händelsen, och gå att ange grupp eller hela verksamheten? Hanterad — båda är åtgärdade. Se RAP-03.
-
#22 Ska fritextfältet heta Händelsen, och hjälptexten skrivas om? Under utredning — rubriken är ändrad, hjälptexten kvarstår. Se RAP-03.
-
#23 Ska rubriken vara Åtgärder som gjordes direkt, med en kortare hjälptext? Under utredning — fältet är nu frivilligt, men ordvalet i rubriken är inte avgjort. Se RAP-03.
-
#24 Ska förslagsfältet heta Förslag på förbättringar, och hjälptexten skrivas om? Under utredning — rubriken är ändrad, hjälptexten kvarstår. Se RAP-03.
-
#25 Kan Avvikelse i vårdkedjan bli en egen avvikelsetyp i version 1.0? Under utredning — verksamheten har lämnat åtta underkategorier och den regionala riktlinjen. Ett arbetsmöte om hur typen passar i processen återstår att boka. Se KAT-01. Avvikelse i vårdkedjan ingick inte i beställningen, men ett flöde som kan passa in har skissats med de berörda. Källa: teamschatten 3 och 11 september, med underlag, och standup 7 oktober. Vid testrundan 8 oktober sades att vårdkedjan kan prioriteras bort om större gränssnittsförändringar krävs.
-
#26 Kan synpunkter och klagomål som kan bli ett missförhållande få en egen avvikelsetyp? Ny — inkommen 11 september. Källa: teamschatten 11 och 15 september.
-
#27 Kan enhetschefen ange en avvikelsetyp per lagrum när två lagrum gäller? Hanterad — en avvikelsetyp för SoL/LSS tillsammans och en för HSL. Se KAT-06. Källa: textändringar för enhetschefssteget 30 augusti, och standup 6 oktober.
-
#28 Ska Meddelanden kunna nå andra än den som skickade in ärendet? Under utredning — meddelanden går till den som skickade in rapporten. Har den rapporterat åt en kollega får enhetschefen ta kontakten på annat sätt. E-postnotisen säger bara att det finns ett meddelande, utan innehåll, så inget sekretessbelagt hamnar i en privat inkorg. Källa: textändringar för enhetschefssteget 30 augusti, och standup 6 oktober.
-
#29 Hur kommer LOV-utförarna åt Draken, och hur begränsas de till HSL? Under utredning — utförarna finns i AD via leverantörsportalen, men åtkomst och avgränsning är inte testade. Se BEH-05, BEH-06. Källa: teamschatten 24 augusti och 2 september.
-
#30 Vilket id ska stå i journalanteckningen för att koppla den till avvikelsen i Draken? Ny — kopplingen kräver ett id som går att knyta till personen. Källa: teamschatten 1 september.
-
#31 Ska polisanmälan och orosanmälan vara valbara åtgärder? Under utredning — verksamhetens underlag har dem som åtgärdstyp, medan IAF vill ha en egen fråga om myndighetsanmälan eftersom lagen styr dem. I dag är polisanmälan en fråga i LEX-utredningen. Se UTR-06. Källa: textändringar för enhetschefsvyn 11 september, och teamschatten 13 september.
-
#32 Ska bedömningen av IVO-anmälan göras innan en utredare tilldelas? Ny. Källa: underlaget om Lex Sarah-flödet, 4 september.
-
#33 Vem anger lagrum och avvikelsetyp vid missförhållande, och får LEX en egen kategorisering? Under utredning — i dag följer enhetschefens kategorisering med och LEX ändrar den inte. Teamet föreslår att LEX-utredaren anger båda. Se KAT-05. Källa: underlaget om Lex Sarah-flödet, 4 september.
-
#34 Ska syftet med åtgärden visas när effekten följs upp? Ny. Källa: textändringar för enhetschefsvyn, 11 september.
-
#35 När kommer de inskickade textändringarna in i testmiljön? Under utredning — texterna ligger inte i testmiljön än, så verksamheten fastnar på sådant den redan gett synpunkter på. Teamet räknar med att föra in dem när sprint 2 börjar 5 oktober. Se RAP-01. Källa: teamschatten 29 september.
-
#36 När ska avvikelsehanteringen driftsättas, och hur hänger det ihop med införandet av Lifecare? Under utredning — teamet behöver svaret för att planera sprint 2. Styrgruppens beslut gällde utbildningen: enhetscheferna ska lära sig mer än att klicka sig igenom systemet, också hur analys, åtgärder och effekter hänger ihop. Utrullning och utbildning stäms av med verksamheten. VoF lyfter frågan mot styrgruppen under veckan 5–9 oktober, och resonemanget startas även med IAF. Teamet föreslår att börja med en liten grupp. Teamet siktar på att vara tekniskt klart med avvikelse- och missförhållandeprocessen under oktober och november. Från IAF finns en första tanke om att starta samtidigt som VoF, gärna vid ett årsskifte, eftersom det underlättar statistik och uppföljning. Ett möte bokas för att forma en plan. Källa: teamschatten 22 september och 7 oktober, och standup 7 oktober.
-
#37 Kan Lex Sarah-fliken och den utskrivna rapporten ha olika namn? Ny — teamet ser inget hinder. Verksamheten tar fram namnen. Se LEX-07. Källa: teamschatten 8 september.
-
#38 Vem får ärendet när enhetschefens chef inte är verksamhetschefen? Ny — i regel är verksamhetschefen enhetschefens chef, men det finns undantag: biträdande verksamhetschefer, och verksamhetschefer som själva är enhetschefer, till exempel på korttidsavdelningar. Se BEH-07 och FLO-05. Källa: teamschatten 2 september.
-
#39 Behövs en utredningsmall för enhetschefen för enbart HSL? Hanterad — nej. Mallarna är två, en för SoL/LSS och en för SoL/LSS med HSL. HSL-mallen har en extra rubrik för bedömning från sjuksköterska eller annan legitimerad personal, vid riskbedömning och allvarlighetsgrad. Se UTR-01. Källa: teamschatten 5 oktober.
-
#40 Vad ska frågan i åtgärdsuppföljningen heta? Löst — frågan heter nu ”Beskriv åtgärdens effekt”, och svaret visas som Åtgärdens effekt i åtgärdslistan och i verksamhetsuppföljningen. Se ATG-06. Verksamheten har bekräftat formuleringen. Källa: standup 6 oktober, koden 6 oktober och teamschatten 7 oktober.
-
#41 Hur loggar personal i hemtjänst och på boenden in — finns de delade telefonerna i tid? Under utredning — delade telefoner är en förutsättning för att hemtjänst och boenden ska kunna använda lösningen. Ansvaret ligger hos välfärdstekniken. VoF siktar på årsskiftet, och IAF har ingen plan ännu. Dialogen om att föra ut lösningen till mobiler har startat, och första testet görs på en vanlig arbetsmobil, eftersom det ska vara samma tekniska väg. Källa: standup 7 och 8 oktober.
-
#42 Vilka av verksamhetens textändringar är införda, och varför inte alla? Under utredning — en stor del av de inskickade texterna är ändrade, men inte alla, och verksamheten vet inte status. Texterna finns i flera dokument, och AI-skissen ligger efter testmiljön. Teamet jämför nu dokumenten med det som är gjort. Uppenbart missade ändringar rättas direkt, och det som är oklart tas på ett gemensamt möte. Källa: standup 8 och 9 oktober.
-
#43 Ska filterfältet på enhetschefens startsida vara dolt som standard? Under omröstning — det blir visuellt lugnare om fältet är dolt, men en del arbetar ständigt med filter och vill ha det framme. Tekniskt går båda. Källa: teamschatten 8 oktober.
-
#44 Ska datum på LEX-utredarens åtgärdsförslag vara frivilliga? Under utredning — utredaren kan inte bestämma när verksamheten ska börja. Alternativen är att datumen är frivilliga för utredaren men obligatoriska för enhetschefen, en ruta ”Ange senare”, eller att enhetschefen ändrar datum när förslaget godkänns. Tills dess kan utredaren skriva förslagen i utredningstexten. Se ATG-03. Källa: testrundan av Lex Sarah-flödet 8 oktober.
-
#45 Hur tar man ut ärenden när media eller en enskild begär ut dem? Under utredning — media begär varje vecka ut förra veckans inrapporterade ärenden med händelsebeskrivning, och cheferna behöver kunna lämna ut uppgifter enligt GDPR. Det finns en första ansats för export och utskrift, men den är inte aktiverad. Teamet visar vad som finns och tar reda på vad som behöver läggas till. Se UPF-09. Källa: standup 9 oktober.
Inga frågor matchar filtret.