Fallstudie
Avvikelsehantering
Ett ärendesystem för avvikelser i LSS-verksamhet. Personal rapporterar, enhetschefen följer ärendet till åtgärdat. Byggt i C# och .NET 8 av någon som rapporterar avvikelser själv.
- Roll
- Allt: domänmodell, regler, gränssnitt, tester, drift
- Byggt med
- C#, .NET 8, Blazor Server, Docker
- Status
- Öppen testmiljö på Render
- Kvalitet
- 16 tester, körs före varje bygge
Problem
På ett LSS-boende händer saker som inte ska hända: ett fall, en dos som ges för sent, en genomförandeplan som inte följs. Varje sådan händelse ska rapporteras som en avvikelse. Att skriva rapporten är sällan det svåra. Det svåra är det som kommer efter: vem som äger den, vad som faktiskt ändrades, och när den kan stängas.
Jag har jobbat på LSS-boenden sedan 2022 och dokumenterar i verksamhetssystemet varje pass. Det här är en egen version av den systemkategorin, byggd från det jag vet om arbetet, inte från en kravlista någon annan skrivit.
Vem använder det
Personal rapporterar vad som hände, var och hur allvarligt det var, och kan flagga en händelse som ett möjligt missförhållande enligt lex Sarah. Formuläret påminner om att skriva vad som hände, inte vem: rumsnummer eller initialer, aldrig namn eller personnummer.
Enhetschefen utser en ansvarig, startar utredningen, följer åtgärderna och avslutar. Översikten visar hur många ärenden som väntar i varje steg, vilka allvarliga som är öppna och hur lång tid det tar i snitt från rapport till avslut. Allt kan exporteras till Excel.
Min roll
Jag byggde allt själv: domänmodellen, reglerna för hur ett ärende får röra sig, gränssnittet, testerna och driftsättningen. Kategorierna, lex Sarah-flaggan och kravet på minst en åtgärd före avslut kommer från hur arbetet faktiskt går till, inte från en mall.
Arkitektur
Lösningen har två delar. Ett kärnprojekt med modellen, reglerna och tjänsten, utan något beroende på webben, och ett webbprojekt i Blazor Server som bara visar och anropar. Kärnan går att testa helt utan webbläsare.
- Reglerna finns på ett ställe. En klass avgör vilka statusbyten som är tillåtna och för vem. Gränssnittet frågar bara vilka steg som finns, och tjänsten kontrollerar reglerna igen innan den sparar.
- Allt eller inget. En ändring görs på en kopia som byts in först när allt gått igenom. Ett regelbrott halvvägs lämnar aldrig en halvändrad avvikelse.
- Historiken skrivs av tjänsten. Varje ändring loggas med vem och när, och gränssnittet kan inte skriva i loggen själv.
- Behörighet på servern. Inloggning med cookie och roller. Exporten skyddas av en policy, inte bara genom att knappen är gömd.
- Lagringen går att byta. Data sparas i en JSON-fil som skrivs atomärt. Tjänsten pratar bara med ett gränssnitt, så en databas kan kopplas in utan att något annat ändras.
Svåraste delen
Att låta reglerna bestämma utan att gränssnittet blir en vägg av gråa knappar. Lösningen blev att skilja på två frågor: har personen rätt roll för steget, och är steget möjligt just nu. Har man rätt roll men något saknas, till exempel en ansvarig eller en åtgärd, visas knappen ändå, låst, med en mening om vad som fattas. Har man inte rätt roll syns steget inte alls.
Resultat
En fungerande testmiljö med påhittade enheter, personer och händelser. Man väljer att vara personal eller enhetschef och kan gå hela vägen från rapport till avslut. Ändrar någon ett ärende uppdateras de andra som har samma sida öppen direkt. Sexton tester täcker reglerna, valideringen och lagringen, och Docker-bygget stannar om något av dem fallerar.
Medvetna begränsningar: testanvändarna har inga lösenord, och data återställs när tjänsten startar om, eftersom gratisnivån saknar beständig disk. Nästa steg är en databas via EF Core och PostgreSQL, riktig inloggning och påminnelser när ett ärende legat still för länge.
Länkar
Testa appen · Källkoden på GitHub
Gratisnivån somnar när ingen använt den på en stund. Första sidladdningen kan ta upp till en minut.