4. Lösningsstrategi
4.1 Strategin i korthet#
| # | Strategiskt val | Vilket mål eller krav det löser | ADR |
|---|---|---|---|
| 1 | Modulär monolit med två fysiskt separerade zoner. En image (Ersvia.Api) som komponerar moduler via IModul, driftsatt som två enheter. Ett projekt och ett schema per modul. Patientdatazonen (personnummer i klartext, egen process, egen DB-roll utan grants mellan zonerna, återidentifiering och utlämningsexport) och ersättningszonen (enbart pseudonym). |
Enkel drift för ett litet team, tydliga gränser, minsta åtkomst (KRAV-18, KRAV-71, KRAV-78) | ADR 0001 |
| 2 | Kontrakt först. OpenAPI 3.1 och AsyncAPI i contracts/, kontraktstester och diff i CI. Legacyformaten bakom en kompatibilitetsfasad. |
Utbytbarhet (KRAV-71), journalsystemen byter bara bas-URL (KRAV-6, KRAV-72) | ADR 0002 |
| 3 | Regler är versionerad data. Beslutstabeller och parametrar med giltighet, beslutsreferens och fyra ögon. Motorn byggs av primitiver (åtta grundprimitiver, tio i regelschemat), och de 42 regeltyperna blir mallar. | Mål 2 (95 % utan utveckling), KRAV-19 till KRAV-23 | ADR 0003 |
| 4 | Bitemporal versionering av allt som styr ersättningen. Valid time och transaction time på varje version, persisterat som en tabell per entitetstyp med exclusion constraint, oföränderlighetstrigger, hashkedja och RLS per huvudman. | "Vad gällde?" och "vad visste vi?" (KRAV-3, KRAV-22, KRAV-55, KRAV-73) | ADR 0004, ADR 0011 |
| 5 | Reproducerbarhet med manifest och hashkedja. En körning låser exakta versions-id, motorversion och underlagssnapshot. | KRAV-36, revisionens krav på spårbarhet | ADR 0005 |
| 6 | Händelsedrivet med transactional outbox. In-process i MVP, utbytbart mot Kafka eller regionens integrationstjänst. | Lös koppling, inga förlorade händelser | ADR 0006 |
| 7 | AI-först med hårda gränser. All AI via IChatClient, bara i ersättningszonen, bara pseudonymiserade data, aldrig belopp, alltid utkast. |
Mål 2 och 4, B4, dataskydd | ADR 0007 |
| 8 | Säkerhet och revisionslogg. mTLS med SITHS, OIDC/SAML, roll och vårdgivare som behörighetsdimensioner, hashkedjad revisionslogg per tenant. | KRAV-6, KRAV-66, KRAV-67, TV-regel 12 | ADR 0008 |
| 9 | Enhetlig domän och öppna standarder. Overenskommelse = Avtal | Uppdrag. Termbankens begrepp, HSA-id och NVID som nycklar, Peppol och FGS. |
KRAV-1, KRAV-37, KRAV-75, KRAV-76, KRAV-79 | ADR 0009 |
| 10 | Produkt för flera regioner. Huvudman är tenant. Regionpaket med regler och kalendrar som data, och adaptrar per region. | Försäljning till andra regioner, KRAV-74, KRAV-79 | ADR 0010 |
| 11 | Stegvis modernisering (strangler fig) med parallellkörning. Fasaden tar över GVR-trafiken först. Beräkningen körs parallellt med ERSMO/HEJ i minst tre månader innan bytet. | F13, risk 1, KRAV-72, KRAV-73 | Kapitel 7.6 |
Lagervyn visar hur strategin knyter ihop verksamhet, applikation och teknologi: verksamhetsprocesserna betjänas av Ersvias applikationstjänster, som i sin tur realiseras av modulerna och körs på den molnneutrala plattformen.
4.2 Hur strategin möter kvalitetsmålen#
| Kvalitetsmål | Taktik |
|---|---|
| Korrekthet och reproducerbarhet | Exakt decimalaritmetik (Belopp) och explicit Avrundningsregel. All tid från IKlocka. Manifest och underlagssnapshot. Golden files (facit) per mall. Egenskapsbaserade tester (FsCheck) för tolftedelar, tak, avrundning och bitemporala invarianter. Parallellkörning mot ERSMO/HEJ. |
| Säkerhet | Zonindelning i kod (arkitekturtest), namnrymd och nät. Pseudonymisering vid zongränsen. Radnivåsäkerhet per huvudman. mTLS. Hashkedjad revisionslogg. Inga personnummer på fakturor. |
| Underhållbarhet | Modulgränser via Kontrakt-namnrymd, NetArchTest, interna lager som internal. Regler som data. Regionpaket i stället för grenar i koden. |
| Prestanda | Partitionering per månad av vardhandelser. Asynkron validering via outbox. Beräkning parallelliserad per vårdgivare och ersättningsgrund. Förberäknade listningsögonblicksbilder på mätdagen. |
| Tillförlitlighet | Outbox med minst en gång-leverans och idempotenta mottagare. Idempotensnyckel (X-Resource-Id, Idempotens-Nyckel). PostgreSQL med WAL-arkivering och strömmande replik (RPO ≤ 1 h). Flera repliker av Api-poddar. |
| Interoperabilitet | Kanonisk modell med indataadaptrar. Nationella tjänstekontrakt. Felkodskatalog som mappar till dagens koder. |
| Flyttbarhet | Kubernetes utan molnspecifika tjänster. Export i öppet format (JSON, CSV, FGS). Regionpaket som går att exportera och importera. |
4.3 Teknikval#
| Område | Val | Alternativ som valdes bort | Motivering |
|---|---|---|---|
| Plattform | .NET 10 LTS, ASP.NET Core Minimal APIs | Java/Spring, Node | Användarens val, LTS-stöd, stark typning för belopp (decimal) |
| Lokal orkestrering | .NET Aspire 13.6 (AppHost startar Postgres 18.3 och Api) | docker-compose | Ingen compose behövs, inbyggd OpenTelemetry-dashboard |
| Databas | PostgreSQL 18 med EF Core 10 och Npgsql 10 | SQL Server, dokumentdatabas | tstzrange, exclusion constraints, RLS, partitionering, öppen källkod |
| Meddelanden | Egen outbox per schema; IHandelsePublicerare in-process, senare Kafka eller Integrationstjänsten |
MassTransit, NServiceBus | Färre beroenden, full kontroll över leveransgarantier |
| Portal | Blazor Web App | React SPA | Samma språk och typer som API:et, server-rendering för tillgänglighet |
| AI | Microsoft.Extensions.AI.IChatClient; Anthropics C#-SDK (claude-opus-5-5) eller lokal modell; FakeChatClient i CI |
Direkt leverantörs-SDK i modulerna | Utbytbarhet, dataminimering, testbarhet |
| MCP | Ersvia.Mcp (MCP-server) |
Egen plugin-modell | Standardprotokoll för AI-klienter |
| Identitet | OIDC/SAML mot regionens IdP; Keycloak i dev; dev-CA för mTLS | Adapter per region | |
| Test | xUnit 2.9, FsCheck 3.6, NetArchTest 1.3, Testcontainers, NBomber, axe | Kravtaggade tester [Krav("KRAV-n")] med JUnit-export till TestViora |
|
| Leverans | Docker, Helm-chart | Molnneutralt | |
| Observability | OpenTelemetry (spår, mått, loggar) | Leverantörsspecifik APM | Öppen standard |
4.4 Organisatoriska strategier#
- Faser enligt den kanoniska fastabellen (planen avsnitt 8, kontroll 3 Ä1): regelmotorn (F3) och beräkningen med lasttest 3× (F6) tidigt, eftersom de är den största tekniska risken, och full legacyparitet (F9) sent. Faserna kopplas till TestVioras tre releaser. Fasplanen finns i kapitel 7.6 och i ArchiMate-vyn a13, och läget i Byggstatus.
- Kravspårning i CI: varje skall-krav har minst ett taggat test eller en dokumenterad mätning (KRAV-35, KRAV-70, KRAV-77). JUnit-resultat laddas upp till TestViora.
- Paritet: paritetsmatrisen för de system som ersätts är en del av definitionen av klart.
- Verksamheten prövar arkitekturen tidigt: workshoppar med controllers och vårdgivare för att motverka risk 2 och 3.
- Levande SAD: det här dokumentet uppdateras i slutet av varje fas, och ändringsloggen visar vad som ändrats.