8. Tvärgående koncept

8.1 Domänmodell#

Kärnan i domänen följer TestVioras informationsmodell (Figur 4 i uppsatsen). Den använder de 24 begreppen i verksamhetsmodellen (ADR 0009). Den är utbyggd för GVR, ListOn, kontroll och flera regioner. Klassdiagrammen visar varje del. ER-diagrammen visar hur delarna lagras per schema. Tabellen visar vem som äger varje mängd data och om den har personuppgifter. Den visar också hur skyddad den är, var den lagras och om den ska sparas eller gallras (tas bort efter en tid).

Förstora

Överenskommelse, vårdgivare och vårdenhet#

Huvudman (tenant, den region som äger datat) har överenskommelser genom en Bestallarnamnd. Overenskommelse är abstrakt. Den är antingen ett Avtal (avtalsnummer, vårdval, LfU-avtalsområde, lagrum LOV/LOU) eller ett Uppdrag (beslutsreferens, egen regi). Den gäller en Vardgivare (organisationsnummer, driftform) med Vardenheter. Den har ett Vardutbud och använder en eller flera Ersattningsgrunder. Typen är en av Kapitering, Uppdrag, Produktion och Målrelaterad, med legacyModellnummer mot ERSMO. Huvudman, vårdgivare och vårdenhet är typer av NIM:s Organisation.

Id-modell (ADR 0011, kontroll 3 Ä5). Ersvias egna id ändras aldrig och är primärnycklar: vg- (vårdgivare), ve- (vårdenhet), ok- (överenskommelse), eg- (ersättningsgrund), bn- (beställarnämnd) och fm- (fakturamottagare). HSA-id och Avtalat uppdrags-id (NVID) är de viktigaste externa id. De lagras som alias med versioner och två tidsaxlar (bitemporalt) i masterdata.alias_version. Där finns också vårdgivarnummer och kombika. Kombika används bara för kompatibilitetsfasaden och historiken, och den ska bort. GET /vardenheter/sok-alias slår upp ett internt id från ett alias, så som det var vid en viss tid (as-of). HSA-id valideras mot ^SE[0-9]{10}-[A-Za-z0-9]{1,24}$. Fakturamottagare tas fram ur län, basområde och hemvist.

Förstora

Vårdhändelse#

Vardhandelse (termbankens vårdkontakt, TestVioras Rapport om utförd vård) är abstrakt med underklasserna Besok, Inskrivning/Vardtillfalle, Aktivitet, Vardperiod och Kontakt. Varje ändring blir en ny VardhandelseVersion. Patienten refereras med Patientreferens (personnummer, samordningsnummer eller reservnummer), som utanför patientdatazonen bara är en Pseudonym.

Förstora

Listning#

Förstora

Regelverk#

Förstora

Beräkning och ersättningsrad#

Berakningskorning har ett Manifest och ett Underlagssnapshot och producerar EkonomiskErsattning per vårdgivare, period och ersättningsslag, uppdelad i Ersattningsrader med Traceposter. Justeringar är egna rader. Differensunderlag refererar den ursprungliga körningen.

Förstora

Fakturering och utbetalning#

Förstora

Mål och vite#

Förstora

Kontroll och ärende#

Förstora

Databasscheman#

Varje modul har ett eget schema med egen historik för migreringar. Den har också tabellerna outbox och dokument. Data med versioner lagras i en tabell per bitemporal entitetstyp (<entitet>_version). Tabellen har giltig daterange, registrerad tstzrange, data jsonb och en hashkedja per nyckel. SchemaSql.BitemporalTabell skapar den (ADR 0011). Alla tabeller har huvudman och säkerhet på radnivå. Diagrammet e04 visar de byggda schemana med det allmänna mönstret (F2–F5). Vårdhändelser (F4) har i stället en egen tabell med partitioner, för att klara volymen (e01, ADR 0012). e01 visar det som är byggt i patientdatazonen, och e02 visar regelverk och identitet. e05 visar beräkning, simulering, FUMS/FUL, kompatibilitet och rapportering (F6 och F9a). e03 visar malrelaterad och granskning (F7) och uppfoljning, migrering och drift (F10). Fakturering och avstämning (F8) finns också i e03.

Förstora

Förstora

Förstora

Förstora

Förstora

8.2 Bitemporal versionering och manifest#

Vad som versioneras: allt som påverkar ett belopp. Det omfattar ersättningsmodeller och regler, parametertabeller (ACG, CNI, DRG-viktlista och poängpris, utomlänsprislista, taxekoder, glesbygdszoner, prisbasbelopp, LPIK), överenskommelser, kodverk, masterdata (vårdenheter, kombika och HSA-giltighet), faktureringskalendrar och källdokumenten själva med SHA-256 (ADR 0004).

Två tidsaxlar:

Bitemporal<T>.GallerAsOf(giltigVid, kandVid) svarar på frågan för en version, och BitemporalHistorik<T> garanterar att högst en version gäller för varje par (giltigVid, kandVid). GiltighetsAnalys hittar luckor och överlapp. IBitemporalLager<T> har två implementationer med samma semantik: in-memory (InMemoryBitemporalLager) och PostgreSQL (PostgresBitemporalLager, EF Core med NpgsqlRange och rådgivande lås per nyckel). Samma FsCheck-modell körs mot båda. I PostgreSQL förhindrar en exclusion constraint (EXCLUDE USING gist (huvudman WITH =, nyckel WITH =, giltig WITH &&) WHERE (upper_inf(registrerad)), btree_gist) överlappande giltighet bland aktuella versioner, och triggern skydda_version gör raderna oföränderliga: bara ersattTid får sättas, en gång, och DELETE är förbjudet (ADR 0011).

Känd svaghet (kontroll 3 R1): en rättelse som bara täcker en del av en tidigare giltighet kräver att den gamla versionen stängs i transaktionstid och att resterna läggs in på nytt, och ersattTid omfattas inte av hashkedjan. Åtgärd: rättelsen görs som en enda operation i lagret (Minus på Giltighet), och stängningen kedjas som en egen händelse.

Prestanda (kontroll 3 R2): manifestet kompileras vid körningens start till en oföränderlig ögonblicksbild i minnet. Motorn läser aldrig bitemporala tabeller per vårdhändelse.

Regler:

• En publicerad version ändras aldrig. En ändring skapar en ny version.
• Ett fel rättas med en ny version med samma giltighet och senare registreringstid. Den gamla får ErsattTid och finns kvar.
• Versionerna kedjas med hash (Hashkedja<T>).
• Varje version har beslutsreferens, källdokument med hash, skapare och godkännare, status och ändringsbeskrivning med diff.

Portalens sida Vad gällde när? (F11a) visar samma fråga för användare, med tidslinje per ersättningsgrund:

Förstora

Exempel (kapitering 75+ och 85+):

Förstora

• "Vad gällde för vård utförd 2026-05-15?" → giltigVid=2026-05-15, kandVid=nu → version B (eller D efter rättelsen).
• "Vad trodde vi gällde för maj när vi räknade 2026-06-03?" → giltigVid=2026-05-15, kandVid=2026-06-03 → version B.
• Majkörningen 2026-06-03 reproduceras exakt ur sitt manifest. Omräkningen 2026-08-25 får ett nytt manifest och ett differensunderlag.

Manifest (ADR 0005): Manifest.Skapa(motorversion, underlagSnapshot, poster) sorterar posterna ordinalt på nyckel och beräknar SHA-256 över kanonisk JSON (KanoniskJson: sorterade nycklar, inga blanksteg, normaliserade tal). Hashen är oberoende av i vilken ordning posterna lades till. Manifest.Id = mf- + de första 16 hexadecimala tecknen och följer med varje ersättningsrad, fakturaunderlag och avstämningsrad. Nycklarna i Beräkningens manifest (F6) är regel/{ersattningsgrund}/{giltigFrån}, parametertabell/{id}, masterdata/vardgivare/{id}, masterdata/vardenhet/{id}, kodverk/{kodverk}, overenskommelse/{id}, konfiguration/berakning, underlag/vardhandelser/{period}, underlag/listning/…, underlag/fums/{period}, underlag/ful/{period}, tidigareKorning/{period} och motor/version. Varje post har versions-id eller referens och hash.

API: alla läs-API:er för versionerad data tar ?giltigVid=<datum>&kandVid=<tidpunkt>. Historik: GET /regelverk/ersattningsgrunder/{id}/historik. Jämförelse: GET /regelverk/jamfor?fran=&till=. MCP: vad_gallde(ersattningsgrund, datum, kand_vid?).

Tester: egenskapsbaserade tester (BitemporalEgenskaper) visar att det inte finns luckor eller överlapp och att as-of-frågan ger högst en version. Ett golden-test kör maj 2026, gör en retroaktiv ändring, kör igen och reproducerar den första körningen bit för bit.

8.3 Regelmotorns primitiver och mallar#

Motorn byggs av primitiver (åtta grundprimitiver nedan, elva i den byggda motorn). De 42 regeltyperna i katalogen (docs/underlag/modeller/00-katalog.md) blir mallar som sätts samman av primitiver. Regionpaketen innehåller bara parametrar och sammansättningar (ADR 0003, ADR 0010). En ny ersättningsform byggs alltså av befintliga primitiver i stället för ny kod (mål 2).

Byggt i F3 (ADR 0013). Regelschemat (contracts/schemas/regel/) och Ersvia.Regelmotor har elva primitiver: de åtta ovan plus villkor, schablon och episod (tillstånd över händelser, tillagd i primitiver.schema.json). Det finns 34 mallar (33 ur schemat plus körsteget clearing för clearing mellan vårdgivare). Alla 42 regeltyper är uttryckta som mall eller variant av mall, utan kodad specialmall; mappningen med facit per typ finns i docs/plan/regelmappning.yaml, och facitfilerna (51 st.) i tests/Golden. Nya ersättningsformer byggs med sammansatt (kedja av primitiver).

Körfaser och beroenden (kontroll 3 Ä11 och R10). Motorn har nio körfaser i ordning – urval, klassificering, prissättning, tillägg/avdrag, tak/målvolym, periodavstämning, pooler/clearing, justering och resultat – grupperade i fyra körnivåer: händelse, vårdgivare och period, pool över vårdgivare och avstämning. Varje mall planeras till namngivna steg, och beroendena bildar en DAG som sorteras topologiskt med fas, regelordning och stegordning som deterministisk prioritet. Ett steg får inte bero på ett steg i en senare fas. Avrundning sker bara med avrunda och en explicit metod (halvUpp, bankavrundning, nedåt, uppåt), per rad eller per summa (nar: perSumma). Belopp är kronor som decimal i motorn och öre i gränssnitten. Varje primitivanrop skriver en tracepost, och resultatet har en SHA-256 över rader, flaggor och trace (KRAV-36). Se f03.

Beslutstabeller med explicit träffpolicy (planen 4k). Varje beslutstabell anger träffpolicy enligt DMN: unik (UNIQUE), forsta (FIRST), prioritet (PRIORITY), alla (COLLECT) och summa (COLLECT-SUM). Överlapp är fel vid publicering för UNIQUE och för PRIORITY med samma prioritet, och luckor är fel när tabellen saknar standardutfall. Uttryck kan skrivas som JSON-träd eller som formel ({"formel": "max(0, x - $troskel) * 0.75"}). Bevis vid publicering: Regelverk kräver minst ett godkänt facitfall och sparar ett hashat testbevis (regelhash, motorversion, fallens utfall) med versionen.

Uttrycken körs i en sandlåda utan I/O, klocka eller slump. Belopp räknas med Belopp och avrundas bara med en explicit Avrundningsregel.

Mallar (42 regeltyper)#

Det finns också mallar för de regeltyper som finns i ersättningsbilagorna:

• tillägg för uppdrag med villkor och kontroll per period
• fast och rörligt led
• ersättning efter tid
• beslut om ersättning varje halvår, i sjättedelar
• tillägg som gäller en viss tid
• volymtrappor som höjer den fasta delen
• pris efter triage (bedömning av hur brådskande vården är)
• målvolym i flera steg
• ersättning i proportion till hur väl målet nås, med villkor om täckning
• mätning vid flera tidpunkter
• viten enligt klausul 10.1, 10.2 och 10.4.2
• egen regi med budget för uppdraget.

Varje mall har ett facittest med ett verkligt exempel ur katalogen. Ett facittest jämför resultatet med ett känt rätt svar.

8.4 Säkerhet#

Zoner#

Zonbrygga, personnummervakt och nycklar (byggt i F12a, ADR 0020)#

Autentisering#

Behörighet#

Behörigheten har tre delar. Den första är roll (TestVioras sex roller). Den andra är vårdgivare, alltså vilka av dem som användaren får se. Den tredje är beloppsgräns (för attest). Identitet översätter claims (uppgifter i inloggningen) till behörigheter. Varje endpoint (adress i API:et) har en policy, en regel för vem som får anropa den. Tabellen över behörigheter följer TestVioras roller:

Delegations- och attestmatris#

Beslutsrätten är konfigurerbar per regionpaket och versionerad bitemporalt, och Identitet kontrollerar den vid varje beslut (planen 4j). Systemet kontrollerar både vem (roll och delegation) och hur mycket (beloppsnivå).

Delegationsmatris (Region Stockholm, gällande delegationer HSN 2026-0052 och PVN 2026-0005):

Attestmatris: beloppsnivåer, utanordnare och attestanter. Egenattest spärras, och över en konfigurerad gräns krävs två personer (GR-5002). Inget attestreglemente är publicerat, så regionen fyller i värdena från HSN:s beslutsordning 2024-0105 och ekonomihandboken. Ändringar i attestanter rapporteras till nämnden varje kvartal. Behörigheter tilldelas utifrån en dokumenterad behovs- och riskanalys per roll och följs upp årligen (NK20, RS 2025-0418).

Pseudonymisering och dataminimering#

• Pseudonym (ett ersättningsnamn i stället för personnummer) = HMAC-SHA-256 av person-id med en nyckel. Nyckeln är unik per tenant och ändamål och ligger i KMS eller HSM (i F2 per huvudman i konfigurationen). Den finns bara i patientdatazonen.
• Återidentifiering, att ta fram personnumret igen, sker bara i patientdatazonen. Ändamålet kontrolleras och allt loggas (NK19). Det behövs för drill-down och utlämningsexport.
• Data med pseudonym är ändå personuppgifter, till exempel vid små celler och ovanliga diagnoser. Därför görs en DPIA (en analys av hur integriteten påverkas). Data slås ihop med k-anonymitet innan de går till AI, så att ingen kan pekas ut (kontroll 3 R5).
• Ersättningszonen får bara ålder på mätdagen, kön, län, kommun och basområde (KRAV-18).
• Inga personnummer i fakturaunderlag till vårdgivare eller i interna fakturor. De använder vårdhändelsenummer eller pseudonym. Vissa utlämnanden kräver identitet enligt regelverk (riksavtalet 8.9, Försäkringskassan EU/EES, Migrationsverket). De skapas av utlämningsexporten i patientdatazonen. Skyddad identitet sköts av sig själv.
• VAL (rättat krav, ADR 0020 tillägg): VAL gör pseudonymer själv och får därför vårdhändelser och listning med personnummer i klartext. Valexporttjanst i patientdatazonen gör leveransen (POST /api/uppfoljning/v1/val/leveranser, som ingressen skickar dit). Ändamålet kontrolleras mot regionpaketets uppfoljning/exporter.json (annars UP-5005). Varje person läses via Personuppgifter med ändamålet. Varje uttag loggas i revisionsloggen och säkerhetsloggen. Leveransen har ett manifest med pseudonymiserad: false. Kontrollen av personnummer, UP-5003, är en uttrycklig inställning per export. Den är avslagen bara för val-vardhandelser och val-listning och påslagen för allt annat. Utfallsexporten innehåller inga personer och ligger kvar i Uppföljning.
• Väntetidsdatabasen, KPP, patientregistret och statsbidragen får underlag med pseudonym, och underlagen kontrolleras mot personnummer. Patientregistret får personnumret när underlaget lämnas in. Det är utlämningsexporten som kopplar på det.

Loggning#

• IRevisionslogg loggar LasningAvPersonuppgifter, Skapad, Andrad, Godkand, Avslagen, Publicerad, Justerad, Attesterad och Inloggning (KRAV-67).
• Loggen är append-only och hashkedjad per tenant (Hashkedja<Revisionspost>). VerifieraAsync hittar den första trasiga posten.
• Loggen lagras per schema i <schema>.revisionslogg(huvudman, sekvens, tid, aktor, handling, objekt, detalj, foregaende_hash, hash) med triggern endast_tillagg och RLS (ADR 0011). Personuppgifter loggar varje läsning med pseudonym, aldrig personnummer i klartext.
• Säkerhets- och åtkomstloggar sparas i minst 5 år (HSLF-FS 2016:40, BG-plan). Stickprov i loggarna dokumenteras.
• Loggarna kan levereras till regionens SIEM och e-arkiv. Säkerhetshändelser tidsstämplas så att regionen kan lämna tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom 1 månad (NIS 2, NK24).

Säkerhetsdrift och NIS 2#

Ersvia omfattas som del av regionens verksamhet av cybersäkerhetslagen (2025:1506). En leverantör som driver Ersvia som tjänst blir själv verksamhetsutövare (förvaltade tjänster). Arkitekturen stöder därför: SBOM per release (CycloneDX i CI, byggt i F12a), Trivy-skanning per image, signerade images, SIEM-export (separat säkerhetslogg-sink), incidentflöde med tidsstämplar (nis2-incidentrutin.md), säkerhetskopiering varje dygn med återläsningstest, revisionsrätt och NIS 2-ansvar i leverantörsavtalet, och säkerhetsskyddsanalys före upphandling (NK25). En ADR om säkerhetsdrift tas fram i F12 (kontroll 3 R7).

8.5 Multi-tenant och regionpaket#

Huvudman är tenant (ADR 0010). ITenantKontext.Huvudman (HuvudmanId, t.ex. exempel eller stockholm) sätts per anrop från token eller certifikat, eller per jobb. Alla tabeller har kolumnen huvudman och RLS-policyer (ENABLE + FORCE) som jämför med current_setting('app.huvudman'). En interceptor sätter värdet med set_config på varje anslutning. Applikationsrollen saknar BYPASSRLS och superanvändare, och lagren filtrerar dessutom explicit på huvudman som försvar på djupet (ADR 0011). Integrationstesterna visar att stockholm och exempel inte ser varandras data. Kvarstående risk (kontroll 3 R9): läckage via poolade anslutningar, bakgrundsjobb och outbox utan tenant. Åtgärd: SET LOCAL per transaktion och ett test som misslyckas om tenant saknas. KSON (kommunalförbund) passar inte modellen "huvudman = region" och modelleras som beställare inom regionens tenant tills vidare. Nycklar för pseudonymisering och kryptering är separata per tenant.

Regionpaketen för stockholm och exempel finns som seed i packages/region-stockholm/ och packages/region-exempel/ från F2.

Regionpaket (packages/region-<namn>/) innehåller allt som är unikt för en region, som versionerad och bitemporal data: regelsammansättningar och parametrar, Kodserver-tabeller, faktureringskalendrar, roller, fakturamottagare med Peppol-adresser, ekonomisystemsadapter, portaltexter och profil (white-label) och begreppsalias. Paketen kan exporteras och importeras i öppet format (KRAV-79). Ett startpaket med nationellt gemensamma regler ingår: riksavtalet, patientavgifter, LOL/LOF-taxan, asyl och EU.

Variation som paketen ska kunna uttrycka: viktlistor med 2–101 åldersgrupper med eller utan kön, ACG-fönster på 15, 18 eller 24 månader, CNI med tröskel och avstämningsrytm, mätdag (1:a, 15:e, 28:e, sista dagen eller dag för dag), utbetalningsdag (5:e, 15:e, 19:e, 20:e eller sista vardagen, ibland förskott) och momskompensation (3,5, 5 eller 6 %).

Verifiering: arkitekturtestet söker efter regionspecifika namn ("Stockholm", "SLL", "HSF") i src/ utanför src/Integrations/. E2E-scenariot körs också mot det fiktiva paketet "Region Exempel". Varje paket levereras med ett körbart scenariobibliotek, eftersom upphandlingar utvärderar på scenarier (till exempel Örebro och Västernorrland med 12 scenarier).

8.6 AI-arkitektur och skydd#

Ersvia är AI-först, men AI påverkar aldrig belopp och ser aldrig personuppgifter (ADR 0007).

MCP-verktyg (byggda i F11a, officiella C#-SDK:t ModelContextProtocol 2.4): vad_gallde, sok_overenskommelse, hamta_regelversion, vardhandelsestatus, listning_ogonblicksbild och forklara_felkod (läsande) samt skapa_regelutkast (skapar bara utkast med status utkast). Autentisering per huvudman med SHA-256-lagrade nycklar; alla svar maskeras mot personnummer, och listning ges bara som aggregat.

Skydd:

1. All AI går via Microsoft.Extensions.AI.IChatClient. Standard i regionpaketet är en lokal eller svensk modell. Anthropics C#-SDK (claude-opus-5-5) eller en annan extern leverantör kräver explicit aktivering per miljö. FakeChatClient används i CI.
2. AI körs bara i AI-zonen och får bara pseudonymiserade eller aggregerade data. En utgående filter-mellanvara avvisar anrop som innehåller mönster för personnummer.
3. AI räknar aldrig belopp. Allt AI-genererat är utkast, märks "AI-genererat" och kräver mänskligt godkännande.
4. Varje anrop loggas med modell, prompt-hash, verktyg, användare och resultat.
5. AI kan stängas av per miljö och per förmåga.
6. En eval-svit (tests/Evals) mäter schematräffsäkerhet, korrekthet mot facit och läckage. Den körs vid byte av modell.
7. Structured outputs valideras mot regel-JSON-schemat innan utkastet sparas (RV-5002 vid fel).
8. En extern LLM klassas som tredjelandsöverföring och biträde och är avstängd tills beslut finns (kontroll 3 R5).

AI-register och klassning enligt AI-förordningen#

AI-registret är byggt i F11a och ligger i docs/plan/ai-register.yaml (version 1.0.0, uppdaterad 2026-11-11). Filen bäddas in i Ersvia.Ai och serveras av AI-tjänsten (GET /ai/register) och portalens sida /ai-register. Ersvia.Ai stänger av en funktion som saknas i registret eller är avstängd, och en högriskfunktion kan inte slås på utan FRIA-referens (art. 27). Förordning: (EU) 2024/1689, ändrad genom (EU) 2026/1744; högriskkraven gäller från 2027-12-02. Regelbaserad beräkning är inte AI, och AI fastställer aldrig belopp eller rätt (NK40).

Riskklasserna är minimal (AI-kunnighet enligt art. 4), transparens (upplysning enligt art. 50) och hög (bilaga III p. 5 a: bedömer fysiska personers rätt till vård eller förmån eller profilerar fysiska personer; kräver FRIA, mänsklig kontroll, loggning och dokumenterad bedömning; avstängd som standard).

Varje svar bär upplysningen: "AI-genererad förklaring (art. 50 AI-förordningen). Kontrollera mot regelrad och orsakskod; belopp och beslut kommer alltid från Ersvias regelmotor och handläggare."

Skydd i varje anrop (F11a): registret, pseudonymiseringsfiltret (personnummer blockerar anropet, namn, e-post och telefon maskeras), beloppsvakten (belopp som inte finns i underlaget tas bort), art. 50-upplysningen och en hashkedjad AI-revisionslogg med prompt, svar, modell, syfte och användare. Loggen är en JSON Lines-fil tills Drift (F12) flyttar den till revisionsloggen i PostgreSQL. Adaptrar: Anthropic (claude-opus-5-5, structured outputs, server-side fallback), lokal OpenAI-kompatibel (svensk drift) och FakeChatClient (CI). Profilen per regionpaket (packages/region-*/ai/ai-profil.json) är av som standard; paketen väljer lokal drift, och extern LLM kräver dessutom Ersvia:Ai:TillatExtern i miljön. Anthropic-adaptern är ännu inte testad mot API:t.

Avvikelseanalys (avvikelseanalys) är registrerad men avstängd; Granskningens deterministiska kontrollregler och riskpoäng (F7) är inte AI.

8.7 Felkodskatalog och kompatibilitet#

Fel returneras som ProblemDetails (RFC 9457) med Ersvias stabila felkod felkod (<PREFIX>-<nnnn>) och legacyFelkod (system, kod), så att vårdgivare och servicedesk känner igen felen (ADR 0002). Katalogen ligger i contracts/legacy/felkoder.yaml.

Katalogen contracts/legacy/felkoder.yaml (F1) har 438 koder och följer numreringen: 0000–1099 har samma nummer som GVR errorCode (GEN, VH, VA), BE-0100–BE-0330 motsvarar ERSMO AFnnn, BE-1000–BE-1999 HEJ Hnnn, FA-0001–FA-0046 VF:s statuskoder, AV-0000/1111/2222/9999 avstämningsstatus OK, Prel, Mak och BeEj, och 5000 och uppåt är Ersvias egna koder.

Felkoderna i SAD:ens körningsvy är synkade mot katalogen:

Orsakskoder (planen 4k): katalogen byggs ut till en publik och versionerad katalog över orsakskoder, i stil med CARC/RARC. Varje kod anger vem som bär beloppet (vårdgivaren, regionen, annan huvudman), vilken åtgärd som krävs (rätta, komplettera, ingen) och är kopplad till den regelrad som gav anmärkningen. Katalogen publiceras tillsammans med kontrakten och versioneras bitemporalt.

Kompatibilitetsregler för kontrakt: OpenAPI-diff i CI. Brytande ändringar kräver ny version (/api/<modul>/v2). Händelsetyper har versionssuffix (.v1). Gamla versioner stöds i minst 12 månader. Legacykontrakten (GVR v1.9.5 och v2.0.0, SNOD-XML, CVR, VF) testas med paritetstester som genereras direkt ur specifikationerna.

8.8 Händelser och outbox#

Förstora

• Integrationshändelser (IIntegrationshandelse.HandelseTyp) namnges ersvia.<Handelse>.v<n> (t.ex. ersvia.VardenhetRegistrerad.v1) enligt AsyncAPI-kontraktet contracts/asyncapi/ersvia-events.yaml (23 händelser i F1). Kanalerna heter ersvia.{huvudman}.<modul>.v1. ADR 0006 är reviderad och anger nu samma form. Interna jobb som inte lämnar modulen har prefixet ersvia.intern. (t.ex. ersvia.intern.ValideringBegard.v1). Händelserna skrivs till modulens outbox i samma transaktion som domänändringen (IOutbox.LaggTillAsync).
• OutboxBearbetare publicerar via IHandelsePublicerare med minst en gång-leverans. Mottagarna är idempotenta, med händelse-id som dedupliceringsnyckel.
• I MVP sker publiceringen in-process. Publiceraren kan bytas mot Kafka eller regionens integrationstjänst utan att modulerna ändras.
• Händelser från patientdatazonen till ersättningszonen pseudonymiseras innan de lämnar zonen.
• Outboxen är persistent per schema (<schema>.outbox) från F2, och händelsen skrivs i samma transaktion som versionen (ADR 0011).
• Händelser som saknas i AsyncAPI-kontraktet och är planerade: ersvia.InsamlingsperiodStangd.v1, ersvia.FolkbokforingAndrad.v1, ersvia.DifferensunderlagSkapat.v1, ersvia.AvvikelseFlaggad.v1, ersvia.KontrollarendeOppnat.v1, ersvia.AterkravBeslutat.v1, ersvia.FakturaunderlagSkapat.v1 och ersvia.AvstamningsfilKlar.v1. De läggs in i kontraktet i den fas som bygger utgivaren.

8.9 API-konventioner#

• REST under /api/<modul>/v1/... (t.ex. /api/masterdata/v1/vardgivare), med en OpenAPI-fil och en server-URL per modul, och svenska resursnamn utan å/ä/ö. JSON i camelCase.
• ?giltigVid=&kandVid= på alla läs-API:er för versionerad data.
• Offsetpaginering med offset och grans (högst 1000), samt X-Totalt-Antal.
• Idempotens med headern Idempotens-Nyckel (UUID) för skrivningar. Samma nyckel och samma innehåll ger samma svar, och samma nyckel med annat innehåll ger 409 (GEN-0409).
• Optimistisk låsning med ETag och If-Match.
• X-Korrelations-Id följer med genom hela kedjan och i OpenTelemetry.
• Långa körningar returnerar 202 Accepted med en Jobb-resurs.
• OpenAPI publiceras på /openapi/v1.json och i regionens API-portal (Anypoint Exchange eller motsvarande).

8.10 Observability#

Telemetrin skickas med OTLP till regionens observabilitetsplattform. Lokalt visas den i Aspire-dashboarden.

8.11 Arkiv, gallring och export#

Byggt i F10 och F12a (ADR 0018, 0020). Detaljerna finns i docs/drift/earkiv-och-gallring.md.

E-arkiv enligt FGS Paketstruktur 2.0#

Jobbet --jobb earkiv --period <år|månad> (CronJob den 15 januari för föregående år) bygger ett informationspaket (SIP) med Ersvia.Arkiv.FgsPaket enligt E-ARK CSIP:

Inte validerat ännu: paketet har inte körts genom Riksarkivets eller E-ARK:s valideringsverktyg. METS- och PREMIS-XSD bäddas inte in, och arkivbeskrivningen är en förenklad XML i stället för EAD. Detta stäms av med Regionarkivet.

Gallring per regionpaket#

Gallringsfristerna ligger versionerade per informationsmängd i packages/region-*/drift/gallring.json med värden ur Regionarkivets BG-planer:

Gallringsjobbet (--jobb gallring [--torr], CronJob per zon) följer fyra regler:

1. Arkivbevarande går först. En källa som ingår i en informationsmängd som ska bevaras spärras helt, och finns den i flera mängder gäller den längsta fristen.
2. Bitemporal gallring. En nyckels versioner gallras bara tillsammans: när alla gällande versioner har upphört att gälla före gränsen och ingen version registrerades eller ersattes efter gränsen. Det som finns kvar har därför alltid hel historik och obruten hashkedja, så att "vad gällde när" fortsatt kan besvaras.
3. Egen roll. Jobbet kör som zonens gallringsroll med DELETE-behörighet; skyddstriggern tillåter DELETE bara när ersvia.gallring = 'pagar' är satt i transaktionen och rollen är medlem. Applikationsrollen kan aldrig radera versionerad data.
4. Spårbarhet. Varje åtgärd loggas som säkerhetshändelse med informationsmängd, frist, fristversion, beslutsreferens, gräns och antal.

Samråd med Regionarkivet krävs före införandet; kopplingen mellan källor och tabeller i gallring.json är ett förslag till det samrådet.

Full export (KRAV-79)#

--jobb export och POST /api/drift/v1/exporter skriver varje informationsmängd som JSON och CSV (RFC 4180, semikolon, UTF-8 utan BOM) med manifest.json (SHA-256, storlek och antal poster per fil). Portalen visar 15 månaders historik; resten finns i arkivet.

8.12 Test och kravspårning#

Tester taggas med [Krav("KRAV-n")]. CI exporterar JUnit-resultat som laddas upp till TestViora, så att kravtäckningen syns där.

8.13 Användbarhet och tillgänglighet#

Portalen (se kapitel 5.5) är en Blazor Web App med server-rendering och följer WCAG 2.2 AA (KRAV-69): tangentbordsnavigering, synlig fokus, kontrast, skärmläsarstöd och felmeddelanden i klartext. Automatiska axe-tester körs i CI, och manuella tester görs med skärmläsare. Användartest före driftstart visar att controllers och vårdgivare klarar en regeländring och en månadsgranskning efter högst en dags utbildning (KRAV-77). Portalen kan märkas med regionens profil (white-label) och har svenska som grundspråk.

8.14 Begrepp och informationsmodell (NIM, VOK och termbanken)#

Planen avsnitt 4h styr hur Ersvias domänmodell förhåller sig till nationella begrepps- och informationsmodeller.

Termbanken som referensdata. Socialstyrelsens termbank 4.3.6 (TBX, CC0) importeras som referensdata i Kodverk. Varje begrepp i domänen har ett termbankTid med stabil länk, och mappningen underhålls i begreppsmappning.csv. Begreppen delas in i fyra grupper (se kapitel 12):

Informationsmodellen följer NIM (E-hälsomyndighetens nationella informationsmodell, informationsstruktur.ehalsomyndigheten.se, JSON-API) och VOK (informationsspecifikationen Organisation och verksamhet):

Diagrammen d01–d08 visar F0/F1-läget. Ändringarna ovan förs in i diagrammen efter F2 och F3 (öppen punkt C.4).

8.15 Förädlingar efter benchmark (planen 4k)#

Benchmarken jämförde Ersvia med 13 lösningar (bland andra NitCore, Privera, Vera Asyl, LOGEX, KUHR, LUNA, KBV Prüfmodul, SUS+, LAMDA/T2A och CMS PRICER) på 33 förmågor. Ingen av dem har bitemporal versionering med transaktionstid, så Ersvia behåller sin egen motor och lånar DMN:s semantik. Följande läggs in i MVP:n:

Förstora

R2 och senare: vårdgivarprognos ("vad får jag?"), inbäddbar validering, DMN-export med Drools som testorakel, en publik referenskalkylator per region och en förvaltningsmodell för flera regioner.

Positionering: modulpaket som kan offereras för 4–6 MSEK (till exempel utbetalning till privata vårdgivare, där Ersvia konkurrerar med NitCore och Privera), en asylmodul (Vera Asyl är i praktiken ensam, och Migrationsverket ställer om sin e-tjänst 2026) och ett körbart scenariobibliotek per anbud. Avtal att bevaka: NitCore Örebro 2028-10-31, Vera Asyl Skåne 2027-12-17 och VGR asyl 2028-04-22.