gevinstkompass

v0.1 — feature-complete. The AI-performed clinical plausibility review is adopted by the owner (2026-07-02); see PHYSICIAN_REVIEW.md. gevinstkompass is a platform- and vendor-independent, health-domain-aware benefits-realisation (gevinstrealisering/nyttestyring) toolkit for velferdsteknologi (welfare technology) in Norwegian municipalities, structured as a real Prosjektveiviseren (Digdir) project. It turns published, sourced assumptions about welfare-technology gains into a deterministic calculator, a machine-readable benefits-realisation plan, and a report a municipality can actually circulate.

The gap

KS' own 2024 survey — FoU 244004, "Gir helseteknologi forventede gevinster?" (Oslo Economics for KS) — found that Norwegian kommuner lack a systematic framework for documenting the gains of health technology, and that planned and realised benefits are almost never compared after the fact. PwC has pointed to benefits-realisation competence as one of the main obstacles to public-sector digitalisation, and welfare-technology job postings very often ask for exactly this competence that the tooling around it doesn't support. gevinstkompass is a small, concrete answer: a sourced assumption library plus a calculator that recomputes every number it publishes from disk, so a kommune can plan a tiltak without inventing its cost model from scratch, and can compare plan against reality once it has real measurements.

Components

• Schema (src/gevinstkompass/schema.py) — pydantic v2 models mirroring Digdir's nyttestyring/gevinstrealiseringsplan columns 1:1 (nyttevirkning, nytteeier, gevinsttype, baseline, maal, indikator, maaletidspunkt, forutsetninger, realisert), with YAML round-trip helpers.
• Nyttevirknings-bibliotek (data/tiltak/*.yaml) — seven velferdsteknologi tiltak (digitalt tilsyn hos hjemmeboende, digitalt tilsyn på institusjon, elektronisk medisindispenser, GPS-lokalisering, elektronisk dørlås, digital trygghetsalarm med responssentertjeneste, digital hjemmeoppfølging — digitalt tilsyn is split by context: home nattkamera-tilsyn computes linearly per bruker, institution pasientvarslingsanlegg/nattbemanning does not), each with parameters carrying full provenance (source title, URL, year, VERIFIED/SECONDARY) traced to docs/research/assumptions-*.md. A number without a fetchable source never enters the catalog.
• Kalkulator (src/gevinstkompass/kalkulator.py) — deterministic projected kroner and frigjort tid per tiltak, per kommune, per antall_brukere. No LLM anywhere in the computation path; the same three inputs always produce the same output.
• Kommuneprofil (src/gevinstkompass/kommune.py) — kommune population parameters from a cached SSB PxWeb snapshot (data/befolkning/befolkning_kommuner.csv), plus a fictive "Fjordvik kommune" (field-wise medians of the real Møre og Romsdal kommuner — each field's median taken independently, so the values may come from different kommuner and the profile is not any one real kommune) used as the worked example so no real kommune's figures are ever presented as measured.
• Nyttestyrings-loop (src/gevinstkompass/nyttestyring.py) — records realisert measurements over time and derives a per-nyttevirkning status (ikke_startet / paa_plan / avvik) plus a projected-vs-realised gap table.
• Verifier (src/gevinstkompass/verify.py) — see The verify contract below.
• Rapport + kanvas (src/gevinstkompass/rapport.py, templates/) — renders the Fjordvik worked example to a bokmål markdown rapport, two matplotlib charts, and two PDFs (rapport + one-page prosjektkanvas) via Jinja2 and weasyprint.

A Digdir-template .xlsx/.csv export of a filled gevinstrealiseringsplan is implemented in src/gevinstkompass/eksport.py (CSV + XLSX in Digdir plan-for-nyttestyring column order); running the rapport pipeline also writes reports/gevinstplan_fjordvik.csv/.xlsx next to the PDFs. Export only — no import in v0.1; see What this is NOT.

Quickstart

Python via uv only — no bare pip/python.

System requirements

weasyprint (used to render the PDFs) needs Pango, cairo, GDK-Pixbuf and HarfBuzz as system libraries. uv sync installs the Python dependency but not these native libraries — without them, uv run pytest and uv run python -m gevinstkompass.rapport fail at import time:

• macOS: brew install pango (pulls in cairo, gdk-pixbuf and harfbuzz as dependencies)
• Debian/Ubuntu: apt install libpango-1.0-0 libcairo2 libgdk-pixbuf-2.0-0

uv sync                                        # install dependencies
uv run pytest                                  # offline, no network — see test count in status.md
uv run python -m gevinstkompass.rapport        # regenerate reports/rapport_fjordvik.{md,pdf} + kanvas + figures.json
uv run python -m gevinstkompass.verify reports/figures.json   # recompute every published figure from disk
uv run python -m gevinstkompass.eksport <plan.yaml> <ut.csv|ut.xlsx>   # export a GevinstPlan to Digdir CSV/XLSX

Everything runs offline: the population snapshot is a cached CSV, the assumption library is YAML on disk, and no step calls out to a language model to produce a number.

Building your own kommune plan

from datetime import date

from gevinstkompass.kalkulator import beregn
from gevinstkompass.kommune import load_kommune
from gevinstkompass.schema import GevinstPlan, dump_plan, load_tiltak

tiltak = load_tiltak("data/tiltak/digital_trygghetsalarm_responssenter.yaml")
kommune = load_kommune("1505")  # Kristiansund — swap in your own kommunenummer
beregning = beregn(tiltak, kommune, antall_brukere=250)  # your kommune's actual user count

plan = GevinstPlan(
    kommune=kommune.navn,
    kommunenummer=kommune.kommunenummer,
    tiltak=[tiltak],
    opprettet=date.today(),
    ansvarlig="Ditt navn / rolle",
)
dump_plan(plan, "min_gevinstplan.yaml")

Then export it to Digdir's column order:

uv run python -m gevinstkompass.eksport min_gevinstplan.yaml min_gevinstplan.csv

beregning carries the projected kroner and frigjort tid beregn() computed for your kommune — inspect it directly, or read beregning.forutsetninger for the source-attributed derivation of every figure, before deciding whether to override any of the tiltak's default parametre (e.g. kommune.kostnader with your kommune's own KOSTRA-derived unit costs).

The verify contract

Every figure a rapport prints is written to figures.json alongside a derivation — enough information to recompute that exact number independently from three sources: the tiltak catalog (data/tiltak/*.yaml), the kommune population snapshot, and the deterministic kalkulator. Before a rapport is generated, gevinstkompass.verify.verify_manifest recomputes every entry and raises a VerificationError naming any figure that doesn't reproduce within tolerance — the language model that writes the rapport's prose never gets the last word on a number. A permanent planted-error test (tests/test_verify.py) proves this actually catches a corrupted figure, not just a well-formed manifest.

uv run python -m gevinstkompass.verify reports/figures.json
# OK: 31 figur(er) i reports/figures.json verifisert mot katalog/kommune/kalkulator på disk.

Deliverables

• reports/rapport_fjordvik.pdf — a bokmål rapport (6–10 pages) walking through the method with a worked example for the fictive Fjordvik kommune: digital trygghetsalarm med responssentertjeneste in detail, medisindispenser briefly.
• reports/kanvas_fjordvik.pdf — a one-page bokmål prosjektkanvas, gevinstkompass's own real project canvas (not a per-kommune template).
• reports/figures.json — the tool-receipts manifest backing every number in both PDFs.
• docs/prosjektveiviseren/ — the project's own real Prosjektveiviseren artifacts (mandat, prosjektbegrunnelse, prosjektforslag, forenklet styringsdokument, gevinstrealiseringsplan), dogfooding the method the package ships.

Sammendrag på bokmål

gevinstkompass er et åpent verktøy som gjør gevinstrealisering for velferdsteknologi maskinlesbart: en katalog med kildebelagte antakelser, en deterministisk kalkulator som regner planlagte kroner og frigjort tid per kommune, og en nyttestyrings-sløyfe som sammenligner plan mot realisert over tid. Hvert beregnede tall verktøyet skriver ut, regnes ut på nytt fra rådata av en egen verifikator før publisering. Se reports/rapport_fjordvik.pdf for regneeksempelet og docs/prosjektveiviseren/ for prosjektets egne styringsdokumenter. Alle tall er planberegning basert på publiserte antakelser — ikke målte gevinster for noen navngitt kommune; se LIMITATIONS.md.

Novelty

So far as we know, gevinstkompass is the only platform- and vendor-independent, health-domain-aware open-source benefits-realisation tool for Norwegian velferdsteknologi. Built on Digdir's own fields, but tied to no platform or vendor. Puzzlepart's prosjektportalen365 (MIT) is the nearest existing open-source tool in this space, but it is Microsoft 365/SharePoint-locked general portfolio-management tooling, not health-domain-aware. This is not an absolute first-mover claim — it is what the available research turned up as of 2026-07.

What this is NOT

• Not clinical decision support. gevinstkompass never recommends a clinical action, dosage, or care decision for any individual. It plans and tracks organisational benefits of technology procurement decisions already made elsewhere.
• Not a chatbot or AI assistant. There is no conversational interface and no LLM in the computation path; a language model is used only to draft narrative prose around numbers the deterministic pipeline already computed and verified.
• Not measured gains. Every figure in a rapport is a planberegning — a projection from published, sourced assumptions applied to a kommune's population parameters — never a measured outcome for any real, named kommune. See LIMITATIONS.md for the full list of approximations this implies (per-innbygger normalisation, national-density stand-ins, year mismatches).
• Not a real patient data product. All inputs are open aggregate KOSTRA/SSB data and published evaluation reports; no real patient or service-level data is used anywhere.
• Not a Digdir importer. The .xlsx/.csv export is implemented (src/gevinstkompass/eksport.py), but v0.1 writes Digdir-shaped files only — it does not read or round-trip an existing Digdir plan.

License

MIT — see LICENSE.

Owner

Built by Oleksandr Altukhov, utdannet lege (master i medisin). PHYSICIAN_REVIEW.md records an AI-performed clinical-plausibility review of each tiltak in the catalog (Claude Fable 5, on the owner's delegation), reviewed and adopted by the owner 2026-07-02. Outward description: «KI-støttet klinisk rimelighetsgjennomgang, gjennomgått og adoptert av eier (utdannet lege, master i medisin)» — never «vurdert av lege».

Further reading

• status.md — live build state.
• docs/CONCEPT.md — concept, schema, scope cuts, rejected alternatives.
• docs/research/assumptions-*.md — every sourced figure the catalog draws on.
• DECISIONS.md — hard constraints and scope-shaping choices.
• LIMITATIONS.md, THIRD_PARTY_SOURCES.md, PHYSICIAN_REVIEW.md — see below.