6. Körningsvy

Körningsvyn beskriver hur byggblocken samverkar i de viktigaste flödena (4+1-processvyn). Varje flöde har ett sekvensdiagram. Tillstånds- och aktivitetsdiagrammen i slutet visar livscyklerna och pipelinerna.

6.1 GVR v2-rapportering via kompatibilitetsfasaden#

Förstora

Så här fungerar flödet som det är byggt i F9a:

1. Journalsystemet anropar POST {bas}/v2/besok på samma sökväg som i dag. Bara bas-URL:en är ny (Kompatibilitet:Gvr:Bas).
2. mTLS: antingen termineras TLS i ingressen, som vidarebefordrar klientcertifikatet i en header (Mtls:VidarebefordratCertifikat, t.ex. X-Client-Cert), eller så går mTLS hela vägen till Kestrel. ASP.NET Core-certifikatautentiseringen validerar kedjan mot regionens rot (SITHS i drift, dev-CA i test), giltigheten och användningen. Spärrkontroll kan slås på.
3. HSA-id hämtas ur certifikatets SERIALNUMBER (2.5.4.5), annars ur CN om det liknar ett HSA-id. IKompatibilitetSystembehorighet (Identitet eller Kompatibilitet:Systemkonton) avgör vilka vårdgivare systemet får rapportera för; annars 403 med errorCode 12.
4. Begäran schemavalideras direkt mot den inbäddade gvr-service-2.0.0.json (400 med GVR:s errorCode vid fel).
5. X-Resource-Id slås upp. En dubblett ger 409 med errorCode 313 (VH-0313).
6. Fasaden översätter till Ersvias kanoniska vårdhändelse (tomt avtal → OVR6001/OVR6002) och registrerar den via IKompatibilitetVardhandelser. Vardhandelser sparar version, idempotens och ersvia.VardhandelseMottagen.v1 i samma transaktion. Valideringen körs som torrkörning synkront, som i GVR (Gvr:SynkronValidering), och den asynkrona valideringen följer (6.2).
7. GVR-specifika fält som inte finns i Ersvias vårdhändelse (akut- och tillgänglighetsfält) sparas i fasadens gvrpost.
8. Svaret är 201 Created med Location.

GVR v1.9.5 (54 operationer, naturlig nyckel), journaler, vårdplatser och kontakter går genom samma fasad. Paritetstesterna (GvrParitetTester) anropar alla 59 + 54 operationer och validerar svaren mot specens scheman. SNOD-XML (POST {bas}/snod/{tjanst}, nio GVRX-tjänster, Basic auth) och CVR-filer (inkorg kl. 07.00, maskinell kvittens) beskrivs i kapitel 5.2.

6.2 Validering och avvisning med AI-förklaring#

Förstora

Så här fungerar valideringen som den är byggd i F4 (ADR 0012):

1. Inskicket (POST /api/vardhandelser/v1/vardhandelser eller /batch) sparar versionen med teknisk status Mottagen, kontroll EjKontrollerad och ekonomisk EjBedomd, och skriver i samma transaktion domänhändelsen ersvia.VardhandelseMottagen.v1 och det interna jobbet ersvia.intern.ValideringBegard.v1 i modulens outbox.
2. Arbetare låser jobben med FOR UPDATE SKIP LOCKED och kör Valideringsregler mot portarna IKodregister (kodverket på vårdhändelsedatumet), IVardenhetsregister, IAvtalsregister och IPatientregister (Personuppgifter, med åtkomstloggning). Portarna kopplas i kompositionsroten Ersvia.Api.Modulkopplingar.
3. Om allt är rätt blir kontrollstatus Godkand (eller GodkandMedAnmarkning) och ekonomisk status Preliminar (AF: OK, Anm eller Prel).
4. Om något är fel blir kontrollstatus Underkand (LF) eller RegionaltFel (RF, t.ex. saknat kodverk eller nere personuppgiftstjänst) med en lista av Regelutfall (felkod ur katalogen, fält, meddelande). RF köas om varje natt.
5. Statusen och ersvia.VardhandelseStatusAndrad.v1 (eller VardhandelseAvvisad) skrivs i samma transaktion. Händelserna bär pseudonym, aldrig personnummer.
6. Felet, utan personuppgifter, ska skickas till Ersvia.Ai för en begriplig förklaring och ett rättningsförslag (F11; i F3–F5 finns bara FakeChatClient).
7. Vårdgivaren rättar med PUT /vardhandelser/{id} (ETag = versionsnumret). Det skapar en ny version, den gamla får teknisk status ErsattAvNyVersion, och valideringen körs igen.

Torrkörning: POST /vardhandelser/validera kör samma validering synkront utan att spara. Svaret har samma felkoder som den riktiga valideringen. Statusen har tre dimensioner (t05).

Tidskrav: valideringsresultatet ska finnas inom 1 timme (KRAV-15). Lasttestet i F4 validerade 70 000 händelser (en dygnsvolym) på 4,2 minuter: inskick 687 händelser/s och asynkron validering 281 händelser/s med 4 arbetare (matningar.md). Flaskhalsen är Personuppgifters hashkedjade åtkomstlogg, som skrivs seriellt per huvudman. Kön övervakas med mått på ålder hos äldsta meddelande. RF-händelser körs om automatiskt varje natt när masterdata eller kodverk har rättats.

6.3 1177-listning via carelisting#

Förstora

1. Invånaren väljer vårdcentral i 1177. Inera anropar Create i supportprocess:logistics:carelisting v2.1 via NTjP/RTP, med länskoden som logisk adress och SITHS funktionscertifikat.
2. Listning kontrollerar personen mot folkbokföringen, att enheten är listningsbar (GetAvailableHealthcareFacilities), att det inte blir fler än 2 omlistningar på 12 månader (annars LI-5001) och listningstaket. Är taket nått hamnar personen i kö med eventuell förtur.
3. Listningen sparas som ett nytt intervall [från, tills vidare) i listning.listning_version, och det tidigare intervallet stängs. ersvia.ListningAndrad.v1 publiceras.
4. På mätdagen (enligt regionpaketets mätdagsregel) skapas en låst ögonblicksbild med AllaAsOf(mätdag, kandVid), aggregat per vårdenhet, åldersgrupp, kön och län, och SHA-256 över posterna. ersvia.ListningsunderlagFaststallt.v1 publiceras.

I F5 exponeras carelisting-operationerna över REST (/api/carelisting/v2/CreateListing m.fl.) i stället för RIVTA via NTjP; anslutning och TAK-registrering bekräftas med Inera. Reglerna kommer från IListningsregelkalla (regionpaketet), inte från Regelverk, och aggregeringen sker i minnet. Sekvensen som den är byggd visas i kapitel 5.2 (s12).

6.4 Månadsstängning och beräkningskörning#

Förstora

Så här fungerar körningen som den är byggd i F6 (ADR 0015):

1. Körningen startas med POST /api/berakning/v1/korningar (period, urval, typ ordinarie). Den körs synkront i anropet och svarar 202 med ett avslutat jobb. I F12 flyttas den till en bakgrundskö.
2. Portarna hämtar regelversioner som gällde någon dag i perioden, parametertabeller, masterdata, kodverk och överenskommelser, vårdhändelsebilden för perioden (och tidigare månaders bilder för ackumulerade regler), listningsbilden per mätdag och listningstyp och FUMS/FUL-underlaget. Personuppgifter slås upp i patientdatazonen; Beräkning får bara härledda fält och pseudonym.
3. Manifestet låser allt med versions-id eller referens och hash (kap. 5.4), inklusive underlag/vardhandelser/{period} och underlag/listning/….
4. Per vårdgivare (6 parallellt) väljs regler via ersättningsgrund eller omfattning, avtalsparametrarna läggs på, och regelmotorn körs i två pass: först ordinarie regler, sedan ackumulerade regler över avstämningsperioden.
5. Raderna summeras per vårdenhet, komponent, patientkategori och mottagare, och fakturamottagaren härleds ur regionpaketet. Trace sparas med källhändelser.
6. Körningen, raderna och trace sparas som dokument. Vårdhändelserna markeras som ersatta, och ersvia.BerakningKlar.v1 publiceras.

Mätning: 2 miljoner vårdhändelser och 2,4 miljoner listade (240 vårdcentraler) beräknades på 4,5 minuter (krav 4 timmar, KRAV-35), 7 330 vårdhändelser per sekund; 3× volym ungefär 13,6 minuter (matningar.md). Toppminnet var 4,5 GB, främst listningsbilden.

Facit och regionpaket: tests/Golden/manad-2026-05 innehåller facit för maj 2026 för Region Stockholm. CI kör en hel månad för både Region Stockholm och Region Exempel (annan mätdag, andra åldersklasser, annan viktlista och 3,5 % momskompensation) utan kodändring.

Begränsningar i F6: efterregistrerade händelser med datum före perioden räknas inte i den faktureringsmånad de kommer in (åtgärdas i F8), och momskompensationen räknas i första passet och omfattar inte ackumulerade regler.

Förstora

6.5 Retroaktiv omräkning, stängda perioder och skuggkörning#

Förstora

1. Nämnden fattar ett beslut med bakåtgående giltighet. Controllern registrerar en ny regelversion, och en annan person publicerar den (fyra ögon).
2. POST /korningar/{id}/omrakning räknar om med nytt kunskapsläge och samma underlag: de låsta vårdhändelse- och listningsbilderna i det ursprungliga manifestet återanvänds.
3. Differensraderna (nytt minus ursprungligt, med ursprungligRadId) hämtas med GET /korningar/{id}/differens. Båda körningarna sparas (KRAV-55).
4. Stängd period: om perioden har en slutlig ögonblicksbild krävs först en torrkörning, och genomförandet måste ha samma manifesthash. Annars ges BE-5004.
5. Reproduktion: POST /korningar/{id}/reproducera kör med exakt samma manifest och ger samma resultathash (KRAV-36).
6. Fakturering (F8) skapar fakturaunderlaget med bara skillnaden.

Skuggkörning (POST /skuggkorningar) kör två regeluppsättningar på samma underlag och visar skillnaderna per vårdgivare och komponent. Den sparas inte som gällande, markerar inga vårdhändelser och publicerar ingen BerakningKlar. Simulering och parallellkörning mot legacy-CSV visas i s13 (kap. 5.4).

6.6 Regeländring med fyra ögon och simulering#

Förstora

1. Controllern skapar ett utkast med POST /regelverk/ersattningsgrunder/{id}/utkast, själv eller från regelassistenten (6.10) eller importen av rapporteringsanvisningar (f02).
2. Simulering kör utkastet mot historiskt underlag och visar det sida vid sida med gällande regelverk per vårdgivare och vårdval (KRAV-64, KRAV-65).
3. Facittestkorare kör golden files (KRAV-23).
4. En annan person granskar och publicerar (/granska, /publicera). Om skaparen försöker godkänna sin egen version blir svaret RV-5001 (KRAV-21).
5. Versionen kedjas med hash, och ersvia.RegelversionPublicerad.v1 publiceras.

Förstora

Publiceringen kör Publiceringskontroll och facittestet i regelmotorn (kap. 5.4, f03). Regelverk kräver minst ett godkänt facitfall i regeldokumentet för att publicera och sparar testbeviset med versionen. Regionpaketen kan publicera en konsultationsversion av nästa års regelpaket (POST /regelversioner/{id}/konsultation).

6.7 Attest och e-faktura till ekonomisystemet#

Förstora

Så här fungerar flödet som det är byggt i F8 (ADR 0019):

1. När granskningen är attesterad (ersvia.UnderlagAttesterat.v1) skapar Fakturering ett underlag per vårdgivare, fakturamottagare och faktureringsmånad. Kvittning och nedsättning från Granskning dras av, och MOMSK-AVTAL läggs på enligt avtalets momsvillkor. Reservnummer utan LMA eller dossier spärras (FA-5006).
2. ersvia.FakturaforslagSkapat.v1 publiceras, och vårdgivaren aviseras.
3. Vårdgivaren godkänner eller invänder (6.8). Vid självfakturering måste vårdgivaren godkänna (FA-5018).
4. Attest sker i två steg mot attestmatrisen. Det finns en spärr mot egenattest: ingen får attestera sitt eget underlag (FA-5019).
5. Egen regi ger en intern budgetjustering (ersvia.BudgetjusteringBokford.v1). Övriga får en Peppol BIS Billing 3-faktura utan personnummer. Den skickas till den mapp som ekonomisystemet läser in från (IEkonomisystem).
6. Kvittensen mottagen kommer direkt i anropet (ersvia.FakturaSkickad.v1). Kvittenserna bokförd, utbetald eller avvisad kommer via POST /kvittenser (ersvia.UtbetalningKvitterad.v1). Betalningsdagen är fakturadatum + 20 dagar.
7. För vårdgivarnas egna ekonomisystem skapar Kompatibilitet VF-bokföringsfilen (.prn) och AF-rapporten i Excel (F9b).

6.8 Vårdgivarens invändning#

Förstora

1. Vårdgivaren ser fakturaunderlaget i portalen. Där står sista dag för att invända. Vårdgivaren kan gå ned i avstämningen per rad.
2. Invändningen anger skälet och de rader som vårdgivaren bestrider (POST /fakturaunderlag/{id}/invandning). Efter sista dagen ger den FA-5002.
3. Beställaren beslutar om invändningen (/invandning/beslut). Får vårdgivaren rätt blir det en justering via Granskning.
4. Beställaren kan föreslå tillägg, och vårdgivaren beslutar. Beslutet går inte att ändra (FA-5003). Men ett tillägg kan krediteras efteråt.
5. När underlaget godkänns flyttas de bestridda raderna till ett eget underlag. De ostridiga raderna betalas ut.

6.9 Utomlänsfakturering via billing:claim#

Förstora

1. Avsändare: Ersvia betalar vårdgivaren för vård av patienter från andra regioner. Sedan begär Ersvia pengarna av patientens hemregion. Fakturering skickar poster med pseudonym (ett ersättningsnamn i stället för personnummer) och ändamålet riksavtalet. De går till utlämningsexporten i patientdatazonen. Där tas identiteten fram igen, och det loggas. För skyddad identitet finns ett remiss-id. Sedan skickas ProcessClaimSpecification per hemregion. Fakturering får bara tillbaka antal, hash och id.
2. Mottagare: Andra regioner anropar POST /api/kompatibilitet/v1/billing-claim/process-claim-specification med mTLS (ömsesidig TLS, där båda parter visar certifikat). Underlaget kontrolleras (KP-5003) och får pseudonym i patientdatazonen. Det blir ett inkommande krav i Fakturering. Kravet godkänns med attest eller bestrids inom 3 månader (FA-5021).

6.10 AI-regelassistent via MCP#

Förstora

1. Controllern använder en AI-klient som ansluter till Ersvia.Mcp med OIDC-token. Verktygen styrs av rollen.
2. Assistenten läser med vad_gallde och hamta_overenskommelse och läser källdokumentet (avtalsbilagan med hash).
3. Ersvia.Ai tolkar bilagan och föreslår en regel med structured output mot regel-JSON-schemat. Ogiltigt schema ger RV-5002.
4. skapa_regelutkast sparar bara ett utkast. Utkastet går sedan genom simulering, facittest och fyra ögon (6.6).
5. Varje anrop, prompt-hash och svar loggas. AI räknar aldrig belopp.

6.11 Kontrollflagga till utredning och återkrav#

Förstora

Så här fungerar flödet som det är byggt i F7 (ADR 0017):

1. POST /api/granskning/v1/perioder/{period}/granskning hämtar ersättningsraderna. Den flaggar avvikelser mot förra perioden. Kontrollmotor kör de publicerade kontrollreglerna.
2. Om regionpaketet slår på riskpoäng får varje vårdgivare en poäng. Den är högst 100 och har en förklaring per bidrag. Poängen är profilering och används bara för urval (kapitel 5.4).
3. Handläggaren öppnar ett ärende, begär underlag (LOL 26 §, LOF 25 §) och föreslår återkrav (LOL/LOF 19 §).
4. En annan person med delegation (IBeslutskontroll, ärendetyp aterkrav) beslutar om återkrav, nedsättning eller ingen åtgärd, med motivering (förvaltningslagen 32 §). Beslutet är ett skriftligt krav. Förfallodagen är 30 dagar senare, och beslutet ger preskriptionsavbrott.
5. Räntan (GET /arenden/{id}/ranta) är referensräntan + 2 procentenheter fram till förfallodagen. Sedan är den + 8. Den räknas per kalenderhalvår. Preskriptionen är tio år och kan avbrytas (/preskriptionsavbrott).
6. Kvittning begärs i ärendet och verkställs av Fakturering (F8).
7. Årsrapporten per nämnd och utförare (GET /arsrapporter/{ar}) redovisar kontroller, avvikelser, ärenden, återkrav, kvittningar, viten och justeringar.

AI fattar inga beslut här. Funktionen avvikelseanalys i AI-registret är avstängd. Riskpoäng för enskilda näringsidkare som AI-funktion är högrisk och därför avstängd (kapitel 8.6). Referensräntorna och beloppsnivåerna i regionpaketets matriser för attest och delegation är bara exempel.

6.12 Livscykler#

Vårdhändelsens status är byggd av tre delar (t05). Kontraktets samlade status och AF-koden tas fram ur dem. Diagrammet t01 visar den samlade statusen.

Förstora

Förstora

Förstora

Förstora

Förstora

6.13 Uppföljning, nationella exporter och parallellkörning#

Förstora

1. Leverans: POST /api/uppfoljning/v1/leveranser bygger ett paket med datafiler och manifest.json för VAL/datalagret eller en nationell mottagare (väntetidsdatabasen, KPP, patientregistret, statsbidrag). Varje nationell fil kontrolleras mot personnummer innan den lämnas ut (UP-5003). Avvikelser från filspecifikationerna (t.ex. tolkad KPP- och patientregisterlayout) redovisas i manifestet.
2. Budgetuppföljning: utfall mot bitemporal budget per nämnd och vårdval (/budgetuppfoljning, KRAV-63) och vårduppdrag i egen regi (/varduppdrag).
3. Skuggning: under parallellkörningen kan GVR-fasaden vidarebefordra autentiserade skrivande anrop till gamla GVR. Ersvias svar gäller alltid, och kön ligger i minnet.
4. Parallellkörning: legacyutfall (AF eller VF V2) importeras, och Migrering jämför per vårdhändelsenummer och sedan per vårdgivare och komponent. En månad är godkänd när ingen skillnad är okänd, och kravet är tre godkända månader i följd (/tackning, risk 1, KRAV-72).
5. Historik: legacyfiler migreras som legacy-körningar med eget manifest-id, och differensen mot en Ersvia-körning är underlaget för retroaktiva rättelser efter bytet (KRAV-73).
6. Integrationsstatus: alla integrationer anmäler körningar till Drift (GET /api/drift/v1/integrationer, KRAV-68).

6.14 Utlämningsexport, återidentifiering och VAL-export#

Förstora

1. Ersättningszonen ser aldrig personnummer. Utlämnanden som kräver identitet begärs via porten IIdentitetsutlamning. Det gäller Försäkringskassan för EU/EES, Migrationsverket och riksavtalet. När zonerna är delade går porten över zonbryggan med ömsesidig TLS.
2. Utlämningsexporten kontrollerar ändamålet (KP-5004). Den tar fram identiteten igen via Vårdhändelser och Personuppgifter, med syfte=utlamning:<ändamål> i åtkomstloggen. Sedan levererar den till mottagaren och skickar bara tillbaka antal, hash och id.
3. På båda sidor av zonbryggan finns en vakt för personnummer. Den stoppar och loggar varje svar som liknar ett personnummer.
4. VAL får vårdhändelser och listning med personnummer i klartext från Valexporttjanst i patientdatazonen, eftersom VAL gör pseudonymer själv (rättat krav, ADR 0020). Uttaget kräver regionpaketets ändamål (UP-5005) och loggas per person och per uttag. Leveranserna hålls i minnet tills vidare.

Zonuppdelat i F12b (ADR 0020, tillägg): Fakturering och Avstämning läser status och brytpunkt via IVardhandelsestatusunderlag (orsakstexter tvättade i patientdatazonen). AF-Excel, VF-.prn och billing:claim produceras i patientdatazonen med underlag från ersättningszonen via IAfUnderlag, IKompatibilitetFakturering och IKompatibilitetReferens. Personnummervakten gäller åt båda håll: ersättningszonen avvisar zonanrop med personnummer i argumenten (422 GEN-0503). Alla F8-flöden är bevisade i delat zonläge av E2E-scenariot.