Om dokumentet
Kapitlen
Introduktion
- Kapitel 1Inledning och målRegion Stockholm betalar varje år ut mer än 100 miljarder kronor till vårdgivare. HSN:s budget för köpt vård 2026 är 77 588 mnkr, och PVN:s …
- Kapitel 2BegränsningarBegränsningarna är givna och går inte att förhandla bort i designen. De kommer från lag, nationella standarder, regionens policyer och användarens …
- Kapitel 3Kontext och avgränsningFigur 1 i uppsatsen visar dagens IT-stöd. Huvudflödet går från journalsystemen via GVR till ERSMO (val av ersättningsmodell), HEJ (prissättning) …
- Kapitel 4LösningsstrategiLagervyn visar hur strategin knyter ihop verksamhet, applikation och teknologi: verksamhetsprocesserna betjänas av Ersvias applikationstjänster, …
Arkitekturvyer
- Kapitel 5ByggblocksvyByggblocksvyn beskriver Ersvias statiska struktur i tre nivåer:
- Kapitel 6KörningsvyKörningsvyn beskriver hur byggblocken samverkar i de viktigaste flödena (4+1-processvyn). Varje flöde har ett sekvensdiagram. Tillstånds- och …
- Kapitel 7DriftsättningsvyErsvia körs i containrar på Kubernetes eller OpenShift och har inga beroenden till molnspecifika tjänster. Helm-chartet deploy/helm/ersvia (byggt …
- Kapitel 8Tvärgående konceptKärnan i domänen följer TestVioras informationsmodell (Figur 4 i uppsatsen). Den använder de 24 begreppen i verksamhetsmodellen (ADR 0009). Den är …
Beslut, kvalitet och risker
- Kapitel 9ArkitekturbeslutBesluten dokumenteras som ADR:er i docs/adr/ . Här sammanfattas de med status, krav, alternativ och konsekvenser. TestVioras tre öppna …
- Kapitel 10KvalitetskravKvalitetsträdet delar upp målen för kvalitet i kapitel 1.4 (ISO/IEC 25010:2023) i scenarier. Ett scenario är ett konkret fall som går att pröva …
- Kapitel 11Risker och teknisk skuldRiskerna R1–R5 kommer från TestViora (sannolikhet och konsekvens på skalan 1–5). R6 och framåt har tillkommit i arkitekturarbetet.
Referens och bilagor
- ReferensOrdlistaOrdlistan kopplar de 24 begreppen i verksamhetsmodellen (TestViora) till Socialstyrelsens termbank (version 4.3.6, hämtad 2026-11-10). Den kopplar …
- BilagaBilaga A. IntressentmatrisMatrisen visar vilka angelägenheter (A1–A14, se Om dokumentet ) som är viktigast för varje intressent och vilka kapitel och vyer de främst bör …
- BilagaBilaga B. VyförteckningFörteckningen listar alla diagram (vyer och modeller enligt ISO/IEC/IEEE 42010). Synsätten S1–S12 beskrivs i Om dokumentet . Källorna är …
- BilagaBilaga C. Öppna punkterÖppna punkter kommer från planen (avsnitt 10 och 11), faktakontrollen ( docs/underlag/verifiering/faktakontroll.md ), underlagen och de diagram …
- BilagaBilaga D. SpårbarhetsmatrisBilagan genereras ur docs/plan/kravtackning.md (som i sin tur genereras av scripts/kravtackning.sh ur JUnit-resultaten efter dotnet test ) och …
- ReferensByggstatusDet här kapitlet visar slutstatus för referensimplementationen: vad som är byggt, hur det är verifierat och vilka avvikelser och luckor som …
- BilagaBilaga E. Sammanfattning för beslutsfattareFör styrgruppen. Läsningstid cirka fem minuter. Detaljerna finns i resten av dokumentet.
Det här är systemarkitekturdokumentet (SAD) för Ersvia, en modulär, API-först och AI-först plattform för all ekonomisk ersättning till vårdgivare. Region Stockholm är första kund, och plattformen byggs som en produkt som ska kunna säljas till fler regioner.
Dokumentet är levande. Det byggs på efter varje fas (F0–F12) och genereras till HTML med docs/arkitektur/rendera.sh. Ändringar görs i kapitelfilerna under docs/arkitektur/kapitel/, och SAD.md genereras från dem. Vad som har ändrats finns i ändringsloggen, vad som faktiskt är byggt finns i Byggstatus, och en kort sammanfattning för styrgruppen finns i Sammanfattning för beslutsfattare.
| Egenskap | Värde |
|---|---|
| Dokument | Ersvia systemarkitekturdokument (SAD) |
| Version | 1.0 (SAD v7, slutversion: F0–F12 klara) |
| Datum | 2026-11-11 |
| Status | Slutversion för granskning och beslut |
| Standard | ISO/IEC/IEEE 42010:2022 (arkitekturbeskrivning), disposition enligt arc42 (12 kapitel) |
| Kompletterande synsätt | 4+1 (Kruchten), C4 (kontext, container, komponent), ArchiMate 3.2, UML 2.5 |
| Huvudkällor | Den kanoniska planen docs/plan/PLAN.md (avsnitt 1–11 och 4a–4l), kontroll 3 (docs/underlag/verifiering/kontroll3.md, ändringarna Ä1–Ä14), koden i src/ (F0–F12), driftdokumentationen i docs/drift/, kravtäckningen i docs/plan/kravtackning.md, ADR 0001–0021, ADR 0001–0010, TestViora-projektet "Ekonomisk ersättning till vårdgivare i Region Stockholm" (K1–K79), uppsatsen Målarkitektur för hantering av ekonomisk ersättning till vårdgivare inom Region Stockholm (v1.0, 2025-06-11), docs/underlag/ |
| Ägare | Arkitekturfunktionen för Ersvia (produkt), med HSF som verksamhetsägare för Region Stockholm |
Syfte och målgrupp#
SAD:en beskriver varför Ersvia ser ut som den gör, vilka byggblock som finns, hur de samverkar under körning och drift, och vilka beslut som ligger bakom. Den används för att:
- ge beställare, controllers och vårdgivare en gemensam bild av vad som ersätts och vad som byggs (kapitel 1, 3 och 4)
- ge utvecklare och testare exakta namn på moduler, API:er, händelser, tabeller och adaptrar (kapitel 5, 6 och 8)
- ge drift, säkerhet och informationssäkerhet underlag för zonindelning, behörigheter, loggning och arkiv (kapitel 7 och 8)
- ge upphandlare och andra regioner en grund för utvärdering, i linje med KRAV-74 (kapitel 4, 9 och 10)
- spåra varje krav i TestViora till byggblock och test (bilaga, spårbarhetsmatris)
Konformitet med ISO/IEC/IEEE 42010:2022#
Standarden säger vad en arkitekturbeskrivning ska ta upp. Den ska visa vilka intressenterna är och vad de bryr sig om (deras angelägenheter). Den ska visa vilka synsätt (viewpoints) som används och vilka vyer som finns. Den ska också visa hur modellerna hänger ihop och varför besluten togs. Tabellen visar var varje del finns.
| 42010-element | Var i dokumentet |
|---|---|
| Systemet av intresse och dess omgivning | Kapitel 3 Kontext och avgränsning |
| Intressenter | Avsnittet Intressenter nedan och intressentmatrisen |
| Angelägenheter (concerns) | Avsnittet Angelägenheter nedan, kopplade till synsätt i vyförteckningen |
| Synsätt (viewpoints) | Avsnittet Synsätt nedan |
| Vyer och modeller | Kapitel 3, 5, 6 och 7, samt verksamhetsvyerna i kapitel 1 och 4. Alla diagram finns i vyförteckningen |
| Modellsamband (correspondences) | Avsnittet Modellsamband och spårbarhetsmatrisen |
| Motiveringar (rationale) | Kapitel 4 Lösningsstrategi och kapitel 9 Arkitekturbeslut, samt ADR:erna |
| Kända avvikelser och öppna frågor | Kapitel 11, öppna punkter och avvikelserna mellan SAD och kod i Byggstatus |
Intressenter#
Intressenterna kommer från TestVioras roller, uppsatsens aktörer (avsnitt 3.1 och 5.3.1), Region Stockholms organisation och produktperspektivet (fler regioner).
| Id | Intressent | Typ | Exempel på angelägenheter |
|---|---|---|---|
| I1 | Beställare: HSN, PVN och KSON, samt den föreslagna Psykiatrinämnden (PSN, RS 2026-0416, inte beslutad) | Beslutsfattare | Budgetföljsamhet, styrning genom ersättningsmodeller, uppföljning (mål 6) |
| I2 | Hälso- och sjukvårdsförvaltningen (HSF) som verksamhetsägare; utförare i egen regi (SLSO, Karolinska, Akutsjukhusnämnden, Ambulanssjukvårdsnämnden) som mottagare av vårduppdrag | Ägare | Korrekt ersättning, intern kontroll, revision, förvaltningskostnad |
| I3 | Avtalsansvarig | Användare | Registrera överenskommelser, ersättningsgrunder och vårdutbud (KRAV-1 till KRAV-5) |
| I4 | Controller | Användare | Ändra regler utan programmering, simulera, granska avvikelser (KRAV-19 till KRAV-23, KRAV-47, KRAV-64) |
| I5 | Handläggare och attestant | Användare | Granska, justera, attestera i två steg (KRAV-48, KRAV-49) |
| I6 | Vårdgivare: privata, idéburna och egen regi, med verksamhetschefer och ekonomer | Användare och mottagare | Snabb återkoppling, transparens, invändning, likviditet (mål 3 och 4, KRAV-50 till KRAV-61) |
| I7 | Journalsystemsleverantörer (TakeCare, Cosmic och privata PAS) | Integratör | Stabila gränssnitt, bara bas-URL ändras (KRAV-6, KRAV-72) |
| I8 | Ekonomifunktionen | Användare | Korrekta underlag, kontering, e-faktura och kvittens (KRAV-53, KRAV-54) |
| I9 | Systemförvaltare, drift och servicedesk (DIT på HSF) | Förvaltare | Integrationsstatus, behörigheter, loggning, återställning (KRAV-66 till KRAV-70) |
| I10 | Informationssäkerhet, dataskyddsombud och arkiv | Granskare | Pseudonymisering, minsta åtkomst, loggning, gallring, e-arkiv (KRAV-18, KRAV-67, KRAV-75) |
| I11 | Revisionen (Revisionskontoret, förtroendevalda revisorer) | Granskare | Kontroll mot felaktiga utbetalningar, spårbarhet (rapport 10/2025) |
| I12 | Nationella aktörer: Inera, E-hälsomyndigheten, Socialstyrelsen, Migrationsverket, Försäkringskassan, SKR | Externa parter | Tjänstekontrakt, kodverk, rapportering, återsökning |
| I13 | Andra regioner (köpare) och upphandlare | Kund | Regionoberoende, moduler som köps var för sig, scenarier, export (KRAV-74, KRAV-79) |
| I14 | Utvecklingsteam, testare och arkitekter | Byggare | Modulgränser, kontrakt, testbarhet, reproducerbarhet |
| I15 | Patienter och invånare | Indirekt berörda | Integritet, korrekt listning via 1177, vårdgaranti |
Angelägenheter#
Angelägenheterna är numrerade så att vyförteckningen kan hänvisa till dem.
| Id | Angelägenhet | Intressenter | Besvaras i |
|---|---|---|---|
| A1 | Vilka system ersätts, och hur sker bytet utan avbrott i utbetalningarna? | I1, I2, I6, I9 | Kap. 3, 4, avsnittet Övergång i kap. 7, ArchiMate-vyerna a06–a08 och a13 |
| A2 | Räknas ersättningen rätt, och kan den räknas om exakt? | I2, I4, I6, I11 | Kap. 6 och 8 (bitemporalitet, manifest), kap. 10 |
| A3 | Kan verksamheten ändra regler själv, säkert och spårbart? | I4, I2 | Kap. 8 (regelmotorn), sekvens s06 |
| A4 | Hur skyddas personuppgifter, och vem ser vad? | I10, I15, I9 | Kap. 8 (säkerhet), zonerna i kap. 5 och 7 |
| A5 | Vad gällde vid en viss tidpunkt, och vad visste vi då? | I4, I6, I11 | Kap. 8 (bitemporalitet), diagram p02 |
| A6 | Hur stöds alla avtalsformer och vårdområden (LOV, LOU, egen regi, LOL/LOF, tandvård, utomläns, asyl)? | I1, I2, I13 | Kap. 1, 3 och 8 (regelmotorn) |
| A7 | Kan Ersvia säljas till andra regioner utan kodändringar? | I13, I14 | Kap. 8 (multi-tenant och regionpaket), ADR 0010 |
| A8 | Hur används AI utan att påverka belopp eller exponera personuppgifter? | I10, I4, I6 | Kap. 8 (AI-arkitektur), sekvens s10, ADR 0007 |
| A9 | Prestanda, tillgänglighet och återställning | I9, I6 | Kap. 7 och 10 |
| A10 | Gränssnitt: stabila, dokumenterade och bakåtkompatibla | I7, I12, I13 | Kap. 3, 5 och 8 (felkodskatalog och kompatibilitet) |
| A11 | Kontroll mot felaktiga utbetalningar och välfärdsbrott | I11, I2, I5 | Kap. 5 (Granskning), sekvens s11 |
| A12 | Arkivering, gallring och export utan inlåsning | I10, I13 | Kap. 8 (arkiv och gallring), KRAV-75, KRAV-79 |
| A13 | Förvaltningsbarhet och uppgraderbarhet utan ny teknisk skuld | I9, I14 | Kap. 4, 9 och 11 |
| A14 | Användbarhet och tillgänglighet (WCAG 2.2 AA) | I3–I6 | Kap. 5 (Portal) och 10 |
Synsätt#
Dokumentet använder följande synsätt. Varje synsätt anger modellspråk och vilka angelägenheter det besvarar. Vyerna som realiserar synsätten listas i vyförteckningen.
| Synsätt | Modellspråk | Angelägenheter | Motsvarighet i 4+1 och C4 |
|---|---|---|---|
| S1 Motivation | ArchiMate motivation | A1, A2, A3, A6, A7 | |
| S2 Verksamhet (aktörer, processer, förmågor, värdeström) | ArchiMate business och strategy | A1, A6 | Scenarier (+1) |
| S3 Applikationslandskap (nuläge, målbild, övergång) | ArchiMate application | A1, A10 | |
| S4 Kontext | C4 kontext, UML | A1, A10 | C4 nivå 1 |
| S5 Logisk struktur (byggblock) | C4 container och komponent, UML komponent och paket | A3, A4, A7, A13 | Logisk vy, C4 nivå 2–3 |
| S6 Information (domän och data) | UML klass, ER, ArchiMate information | A2, A4, A5, A12 | Logisk vy |
| S7 Beteende (körning) | UML sekvens, tillstånd och aktivitet | A2, A3, A8, A11 | Processvy |
| S8 Utveckling | UML paket, repostruktur | A7, A13 | Utvecklingsvy |
| S9 Driftsättning | UML deployment, ArchiMate teknologi | A4, A9 | Fysisk vy |
| S10 Användning | UML användningsfall | A14, A6 | Scenarier (+1) |
| S11 Migration och implementation | ArchiMate implementation och migration | A1 | |
| S12 Tid (bitemporalitet) | UML timing | A5 |
4+1 i dokumentet#
| 4+1-vy | Kapitel och diagram |
|---|---|
| Logisk vy | Kapitel 5 (byggblock), klassdiagrammen d01–d08 |
| Processvy | Kapitel 6 (körning), sekvensdiagrammen s01–s11, tillstånd t01–t04, aktivitet f01–f02 |
| Utvecklingsvy | Kapitel 5.4 (paket och repostruktur), k03 |
| Fysisk vy | Kapitel 7 (driftsättning), p01 och a11 |
| Scenarier (+1) | Kapitel 6 och 10 (kvalitetsscenarier), användningsfallen u01–u03 |
Modellsamband#
Modellerna hänger ihop genom följande samband. De kontrolleras vid varje fas, och matrisen i bilagan uppdateras.
| Från | Till | Samband | Regel |
|---|---|---|---|
| TestViora-förmåga (F1–F13) | Modul | realiseras av | Varje förmåga realiseras av minst en modul (a04, kap. 5) |
| TestViora-krav (K1–K79) | Byggblock och test | uppfylls av, verifieras av | Varje skall-krav har minst ett taggat test [Krav("KRAV-n")] eller en dokumenterad mätning (matrisen) |
| Begrepp (24 i verksamhetsmodellen) | Klass, tabell, API-resurs | namnger | Samma namn utan å/ä/ö i identifierare (ADR 0009, ordlistan i kap. 12) |
| Informationsmängd (10 i TestViora) | Schema och informationsobjekt | lagras i | a10 och e01–e03 |
| Process (7 i TestViora) | Sekvensdiagram | utförs av | a03 och s01–s11 |
| Roll (6 i TestViora) | Behörighet i Identitet | tilldelas | Kap. 8 (säkerhet), u01–u03 |
| ArchiMate application component | C4 container och UML komponent | motsvarar | Samma modulnamn |
| ADR | Kapitel och krav | motiverar | Varje beslut i kap. 9 anger ADR och krav |
| Funktion i system som ersätts (ER-01 … FL-06) | Modul och test | paritet | Paritetsmatrisen (kap. 3) |
Konventioner#
- Krav skrivs
KRAV-n(samma id som TestViora Kn och testtaggen[Krav("KRAV-n")]). - ADR skrivs
ADR 000noch länkar tilldocs/adr/. TestVioras tre öppna beslut kallas TV-ADR 1–3. - Identifierare i kod, API och databas skrivs utan å/ä/ö (
Vardhandelse,Overenskommelse). Brödtexten använder de svenska begreppen. - Diagram har prefix efter typ:
aArchiMate,cC4,kkomponent och paket,dklass,eER,ssekvens,ttillstånd,faktivitet,pdriftsättning och tid,uanvändningsfall. Källan är.pumlidocs/arkitektur/diagram/, och SVG renderas med PlantUML 1.2025.4 i Docker. - Status på påståenden följer underlagen: verifierat i källa eller slutsats. Påståenden som ska verifieras med förvaltningarna finns i öppna punkter.