likeperson.md

1# Tverrgående workshopsammendrag
2
3## Behovskartlegging – Likepersonsapp
4
5**Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen, Norse Test Organization**
6**Version 7.0.0**
7
8Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund, Hørselsforbundet (HLF), Barnekreftforeningen og Norse Test Organization. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling.
9
10> **Note on reuse.** Parts of this document describe patterns (module toggles, area taxonomy, decoupled auth module, organization labels) that are specific to *this* platform's multi-tenant, multi-organization shape. Other products generated from a source doc via the same pipeline will not necessarily share that shape — a single-tenant SaaS, an internal tool, or a fixed-scope deliverable typically should **not** adopt module toggles or per-tenant label overrides. Each architectural pattern below is scoped with an applicability note; treat them as options justified by stated constraints, not defaults.
11
12## 1. Felles behov – går igjen i alle fire organisasjoner
13
14Følgende behov ble løftet frem – ofte ord for ord – i alle workshops. Dette er kjernen i hva appen MÅ løse.
15
16### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle)
17
18Alle fire organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller.
19
20- **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk.
21- **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst.
22- **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle.
23
24> **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg.
25
26### 1.2 Universell utforming (WCAG 2.2 AA)
27
28Alle fire organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner – fra dag én, for alle organisasjoner. Ingen organisasjon er unntatt eller utsatt til senere fase.
29
30- **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå.
31- **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle.
32- **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning.
33- **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter.
34- **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size).
35- **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator.
36- Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen.
37- Varsling ved opplesning av sensitive felt (NHF).
38- **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements).
39
40### 1.3 BankID / Vipps innlogging
41
42Alle fire organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. **MVP leveres med e-post/passord-innlogging; BankID og Vipps ruller ut i Fase 2** (se §5 og prioriteringsmatrisen i §4). Denne seksjonen beskriver den langsiktige foretrukne tilstanden, ikke MVP-scopet. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere.
43
44### 1.4 Sømløs Bufdir-rapportering
45
46Alle fire organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. **Rapporteringsdata samles inn gjennom aktivitetsregistrering i mobilappen**, men **selve Bufdir-eksporten er en admin-funksjon**: organisasjonsadministrator kjører eksporten fra Admin Web Portal. Koordinatorer og likepersoner logger kun inn på mobilappen og har dermed ikke tilgang til eksportfunksjonen. Mobilappen har ikke Bufdir-eksport som funksjon – kun registrering. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene.
47
48### 1.5 Inkrementell utrulling – parallelle systemer
49
50Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg.
51
52- **NHF:** «Ikke steng det gamle før folk er klare.»
53- **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side.
54- **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling.
55
56### 1.6 Testoppsett: TestFlight (iOS) + Apptester (Android), 5–8 personer, én kontaktperson
57
58Alle fire organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight og Android-distribusjon via Apptester på lik linje, 5–8 testpersoner per plattform med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren.
59
60## 2. Delte behov – nevnt av to eller flere organisasjoner
61
62Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt. Det autoritative per-org-bildet er prioriteringsmatrisen i §4 – narrativet her forklarer mønsteret bak.
63
64### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet)
65
66Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav:
67
68- Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett).
69- Kvitteringsbilde for utlegg over 100 kr (HLF).
70- Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF).
71- Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet).
72- API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF).
73
74### 2.2 Gamification og synliggjøring av innsats (NHF + HLF + Barnekreftforeningen)
75
76Tre organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer. Blindeforbundet har ikke samme behov og ser det som mindre relevant.
77
78### 2.3 Pausefunksjon for likepersoner (NHF + HLF + Barnekreftforeningen)
79
80Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk. Blindeforbundet håndterer dette manuelt og har ikke fremhevet behovet.
81
82### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF + Barnekreftforeningen)
83
84Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere). Blindeforbundet bruker ikke proxy-rapportering på samme måte og prioriterer dette lavt.
85
86### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF)
87
88Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving.
89
90## 3. Unike behov per organisasjon
91
92### 3.1 Norges Blindeforbund – unike behov
93
94- **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag.
95- Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet.
96- **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15.
97- **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren.
98- Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale.
99- **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker).
100- **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager.
101- Gradvis digitalisering av fullmakter og epikriser med manuelt fallback.
102
103### 3.2 Norges Handikapforbund – unike behov
104
105- **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne.
106- **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering.
107- **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer.
108- **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving.
109- **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes.
110
111### 3.3 Hørselsforbundet – unike behov
112
113- **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel.
114- **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt. (Barnekreftforeningen har et beslektet behov og er også markert i matrisen.)
115- **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre.
116- **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering.
117- **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel).
118
119### 3.4 Barnekreftforeningen – unike behov
120
121- **Pårørende-database:** Barnekreftforeningen jobber primært med familier rundt barn med kreft, ikke kun med de berørte selv. Appen må støtte registrering av pårørende (foreldre, søsken, nærmeste omsorgsperson) som egne kontaktsubjekter knyttet til samme sak.
122- **Formalisert rapportstruktur** (delt med Blindeforbundet): kort strukturert etterrapport etter hjemmebesøk eller samtale, som fungerer som bestilling til koordinator.
123- **Kursadministrasjon** (delt med HLF) for opplæring av nye likepersoner og oppfølgingskurs.
124- Øvrige fellesbehov (bulkregistrering, pausefunksjon, gamification) er beskrevet i §2 – Barnekreftforeningen inngår der også.
125
126### 3.5 Norse Test Organization – unike behov
127
128Norse Test Organization er en intern testorganisasjon opprettet av Norse Digital Products for å validere hele plattformen end-to-end med full moduldekning. Den er ikke en reell kundeklient, men representerer en tenkt organisasjon som har aktivert alle tilgjengelige moduler og funksjoner.
129
130- **Full modulaktivering:** Alle togglable moduler er aktivert — inkludert expense-reimbursement, encrypted-assignments, certification-training, achievements-gamification, geographic-map-view, mentor-program, relatives-database, referral-program og alle øvrige.
131- **Testformål:** Sikre at kombinasjonen av alle aktiverte moduler ikke gir konflikter i navigasjon, API-respons, eller admin-portal.
132- **Alle matrisefunksjoner:** Norse Test er eneste organisasjon med ✓ på absolutt alle behovspunkter i §4-matrisen.
133- **Ingen organisasjonsspesifikke begrensninger:** Terminologi, labels og config-flagg er satt til standardverdier for å unngå at org-spesifikke overrides skjuler feil i standardoppsett.
134- **Brukes ikke i produksjon:** Data generert av Norse Test-organisasjonen er testdata og skal ikke inngå i Bufdir-rapportering eller øvrig ekstern rapportering.
135
136## 4. Behovsoversikt – prioriteringsmatrise
137
138> **How to read this matrix.** It is a workshop snapshot of divergent stakeholder needs — the input that motivated the module-toggle architecture below. It is **not** a development spec and should not drive per-organization code branches. Authoritative per-org scope lives in the module toggle registry (see *Module Toggles per Organization*). The Prioritet and Fase columns are indicative only; the current roadmap lives in sections 5 and 7 and will drift as priorities shift.
139
140| Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Norse Test | Prioritet | Fase |
141|-|-|-|-|-|-|-|-|
142| Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
143| Universell utforming / tilgjengelighet (WCAG 2.2 AA) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
144| BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |
145| Bufdir-rapportering (eksport, admin) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |
146| Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
147| TestFlight (iOS) + Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
148| Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 |
149| Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | ✓ | NICE TO HAVE | 3 |
150| Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 |
151| Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 |
152| Tale-til-tekst | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 |
153| Kryptert oppdragshåndtering | – | – | ✓ | – | ✓ | MUST (Blindeforbundet) | 2 |
154| Formalisert rapportstruktur | ✓ | – | ✓ | – | ✓ | NICE (Blind. + Barnekreft) | 3 |
155| Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | ✓ | SHOULD (HLF + Barnekreft) | 3 |
156| Koordinering med ekstern portal | – | – | – | ✓ | ✓ | MUST (HLF) | 2 |
157| Dokumentvedlegg til aktiviteter | – | ✓ | – | – | ✓ | NICE TO HAVE | 2 |
158| Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
159| Snakkekort | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 3 |
160| Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 |
161| Pårørende database | ✓ | – | – | – | ✓ | MUST (Barnekreft) | 1 |
162| Basic search (contact og notater) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
163| Notater | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 |
164| Verving / Referral (invite-link, rekruttering) | – | – | – | ✓ | ✓ | SHOULD (HLF) | 3 |
165
166### Product Landscape — Meander Platform
167
168Meander is the platform. It ships as four distinct products, each serving different users and purposes. The **two operational products** (Mobile App + Admin Web Portal) share the same database and the same authentication module. The Authentication Module is a decouplable service shared by them. The Sales Website is a separate public information site with no auth, no database access, and no shared runtime — it only links out to marketing content.
169
170**Product 1: Meander Mobile App** (Flutter)
171- Purpose: Day-to-day operational tool for peer mentors and coordinators
172- Users: Peer Mentors (Likepersoner), Coordinators (Organization Admins appear as Coordinators on mobile)
173- Core capabilities (always available):
174  - Activity registration (quick logging, wizards, bulk/proxy)
175  - Contact and peer mentor management
176  - Personal statistics and impact summaries
177  - Push notifications and assignment tracking
178- Optional capabilities (toggled per organization):
179  - Travel expense registration (`expense-reimbursement`)
180  - Speech-to-text input (config flag on `activity-registration`)
181  - Document attachments to activities
182  - Gamification — wrapped summaries, badges (`achievements-gamification`)
183  - Encrypted assignments (`encrypted-assignments`)
184  - Course registration & certification (`certification-training`)
185- Tech: Flutter, Riverpod (no codegen), Drift (offline), WCAG 2.2 AA
186
187**Product 2: Admin Web Portal** (Next.js)
188- Purpose: Organization management, reporting, and oversight
189- Logged-in users: Organization Admins, Global Admins. Coordinators and Peer Mentors are **managed** inside the admin portal (invitations, role assignment, deactivation) but never log in to it — they only log in to the Mobile App.
190- Core capabilities:
191  - User management (invite, deactivate, role assignment)
192  - Organization settings and terminology/labels configuration
193  - Bufdir report generation and one-click export
194  - Activity oversight, approval workflows, and corrections
195  - Reimbursement approval and expense oversight
196  - Coordinator and organization-level dashboards and KPIs
197  - Multi-organization hierarchy management
198  - Course and certification administration
199- Tech: Next.js on Vercel, server-side rendering, same auth system
200
201**Product 3: Authentication Module**
202- Purpose: Issue and validate credentials for every Meander product. Treated as its own product — not a feature of any single product — because it must be decouplable and movable into its own service or repository at any time without forcing changes on consumers.
203- Users: Every other Meander product that needs to know who a user is: Mobile App, Admin Web Portal, and any future product, partner, or integration.
204- Core capabilities:
205  - Email/password sign-in for MVP; BankID and Vipps in Phase 2
206  - Short-lived access tokens plus rotating refresh tokens
207  - Session revocation (sign-out, forced expiry, admin-initiated)
208  - Per-tenant isolation of signing material
209  - A clean extension point for attaching product-specific claims (role, organization memberships) without the auth module knowing the product's schema
210- Boundaries:
211  - Owns only identity and session state. No product data, no authorization logic, no role semantics.
212  - Authorization (who can do what within a product, tenant scoping, audit of domain actions) is the consuming product's responsibility.
213  - Exposes a stable contract (sign-in, sign-out, refresh, identity lookup) so consumers do not depend on its internals.
214- Portability requirement: the module must be extractable into a standalone service or repository later without API changes for consumers. This rules out reaching into product tables, coupling to product frameworks, or leaking product concepts into tokens beyond a generic claims bag.
215
216**Product 4: Product Sales Website** (simple static site)
217- Purpose: Public information site for prospective organizations — explains what Meander is, shows features, and collects demo requests.
218- Users: Prospective organizations, buyers, decision-makers
219- Scope: **Information-only.** No authentication, no user accounts, no database, no shared runtime with the operational products. A demo-request form may POST to a lightweight form handler (email/webhook), but nothing more.
220- Core capabilities:
221  - Product landing page and feature overview
222  - Benefit / impact calculator (static calculation, no login)
223  - Demo booking form
224  - Privacy policy, Terms of Service, Data Processing Agreement, Cookie Policy
225- Tech: Static site (Next.js static export, Astro, or plain HTML/CSS). Public-facing, no auth, no backend dependency.
226
227### Module Toggles per Organization
228
229> **Applicability.** This pattern applies to multi-tenant products whose tenants have materially divergent needs (the Meander case: four organizations with partly overlapping feature sets). Single-tenant products, or products where every tenant uses the same feature set, do **not** need module toggles — the added config surface is overhead without benefit. When adopting this pattern from a source doc into a new product, first confirm the tenancy and divergence actually justify it.
230
231Not every organization needs every capability. The needs matrix shows features that are must-have for one organization and irrelevant for another (e.g. encrypted assignments for Blindeforbundet, course administration for HLF, document attachments for NHF). Rather than branching the product per organization, the platform treats each functional area as an independently toggleable module.
232
233**Design intent:**
234
235- **Module = Area.** The canonical areas defined in the area taxonomy (section 8) are the unit of toggling. Each area ID (e.g. `expense-reimbursement`, `encrypted-assignments`, `certification-training`) is a module that can be enabled or disabled per tenant. This keeps the registry generic — no hand-maintained feature flag list parallel to the area taxonomy.
236- **Admin surface owns the switch.** Whichever product serves as the administrative surface (here, the Admin Web Portal) exposes the toggles under Organization Management → Feature Toggles. The enabled set is persisted as tenant configuration.
237- **Backend is the source of truth.** The API exposes the enabled module set for the current user's tenant as part of the session/bootstrap response. Every endpoint that belongs to a module checks the tenant's enabled set before executing — clients cannot bypass a disabled module by calling the API directly.
238- **Clients load generically.** Clients (mobile, web, partner integrations) do not hardcode which tabs, entry points, or screens exist. At startup each client reads the enabled module set and renders only the navigation, surfaces, and flows belonging to enabled modules. Disabling a module hides its UI entirely; re-enabling restores it without a client release.
239- **Always-on core.** A small set of modules is non-toggleable because the operational products are meaningless without them. Each operational product has its own always-on set:
240  - **Mobile App:** `authentication-access-control`, `home-navigation`, `accessibility`, `help-support`, `profile-management`.
241  - **Admin Web Portal:** `admin-dashboard`, `admin-user-management`, `admin-organization`, `admin-security`. `admin-organization` is always-on because it hosts the Feature Toggles UI itself — disabling it would remove the only place toggles can be re-enabled (circular dependency).
242  - The Sales Website is out of scope for module toggles entirely — it is a static information site with no module concept.
243- Other products reusing this pattern should define their own always-on set based on what is universally required and which module (if any) hosts the toggle-management UI.
244- **Dependencies between modules** are declared in the registry, not inferred. If module A requires module B, enabling A implicitly enables B; the admin UI makes this visible rather than failing silently at runtime.
245- **Area toggle vs config flag.** Toggle a whole area when the full workflow (UI, API, admin tooling) appears or disappears together. Use a config flag inside an area when only one dimension varies (e.g. speech-to-text on `activity-registration`, receipt-required threshold inside `expense-reimbursement`). Prefer the lighter option; promote a config flag to its own area only when a second tenant actually diverges.
246- **No per-tenant code paths.** Tenant-specific behavior lives in (a) the enabled module set, (b) a terminology/labels system for display strings, and (c) per-module configuration values. New tenants onboard by picking modules and labels, never by shipping code.
247
248This keeps the codebase single-tenant in shape while supporting multiple organizations with materially different needs, and leaves room for new tenants without a rewrite.
249
250### Core Roles & Access Boundaries
251
252Each organization has its own roles and users. Norse (the platform owner) manages global admins separately.
253
254**4 defined user roles:**
255
256- **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Logs in to the Mobile App only. Beginner-level digital skills assumed. Managed (invited, assigned, deactivated) by Org Admin from the admin portal, but does not log in to the admin portal.
257- **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Logs in to the Mobile App only. Like Peer Mentors, Coordinators are managed from the admin portal by Org Admin but do not have admin portal login access.
258- **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Logs in to the admin portal (primary surface). **On mobile, an Org Admin is surfaced as a Coordinator** — they use the same mobile experience as coordinators without a separate UI path. Admin-only capabilities (user management, reports, toggles) live exclusively in the admin portal.
259- **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. **No default access to an organization's operational data (users, activities, contacts).** Tenant separation is strict: each org's data is isolated. Orgs can grant a Global Admin *time-bounded* support access via a flag in Organization Settings (e.g. "Allow Norse support access until {date}"); revoking the flag or hitting the expiry immediately removes access. Every support-access session is logged in the org's audit trail.
260
261### Core Operational Flow
262
2631. Peer mentor performs activity or event
2642. Activity is registered and tracked in Meander Mobile App
2653. Coordinator oversees follow-up, quality, and approval
2664. Org Admin gets overview in Admin Web Portal
2675. Structured data supports Bufdir reporting and analytics
268
269### Shared Backend
270
271Shared only by the **operational products** (Mobile App + Admin Web Portal). The Sales Website does not touch this backend.
272
273- **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`)
274- **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR)
275- **Database** (standard relational, managed) — no vendor-specific extensions, pure SQL with migrations
276- **Authentication:** Handled by the Authentication Module (Product 3), treated as a decoupled product so it can be moved into its own service or repository later without forcing changes on consumers. Issues short-lived access tokens plus rotating refresh tokens; sessions survive silently across token expiry and end cleanly when the refresh chain is broken. Email/password for MVP; BankID/Vipps in Phase 2. Biometric session unlock (Face ID / fingerprint) after first login. Mobile stores tokens in the platform secure store; admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context). Authorization — roles, organization scoping, tenant isolation — is the consuming product's responsibility, never the auth module's.
277
278### Mobile App Architecture
279
280**Auth & Access**
281- **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login.
282- Email/password login
283- BankID / Vipps login (Phase 2)
284- Biometric session authentication (Face ID / fingerprint)
285- Role-based access control — Peer Mentor and Coordinator roles
286- No-access screen for Global Admin (redirected to admin portal)
287
288**Navigation**
289- Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications
290- Settings accessible from hamburger menu
291
292**Screens**
293- Role-specific home content (peer mentor vs coordinator variants)
294- Contacts list with role-specific views
295- Contact detail, edit, and peer mentor profile screens
296- Activity wizard (multi-step: contact → date → time → duration → summary)
297- Event wizard (multi-step: title → date → time → duration → location → summary)
298- Settings and preferences
299- Notification inbox
300
301**Core/Shared**
302- REST API client (`ApiHttpClient`) with JWT bearer, auto-refresh on 401, 15s timeout, and a typed `ApiException` hierarchy
303- Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver)
304- Optimistic mutations with automatic rollback on failure (contact edits and paginated list updates)
305- Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant
306- Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table
307- Organization labels system — per-org terminology overrides fetched from backend and cached offline (currently: `contacts`, `my_contacts`, `peer_mentors`; extensible to singular forms and role terms such as `peer_mentor`, `coordinator`, `contact`)
308- Module registry — the app's navigation, home surfaces, and entry points are assembled at runtime from the enabled module set returned by the backend. Each area from section 8 registers its nav item, home widgets, and deep links against its area ID; disabled modules are simply not mounted. No compile-time switching per organization.
309
310## 5. Anbefalt prioriteringsrekkefølge for teamet
311
312Fasene her speiler aksjonspunktene i §7. Fase 0 er mobiliseringsfasen (pre-utvikling) og er beskrevet i §7. Fase 1–4 nedenfor er utviklingsfasene.
313
314### Fase 1 – MVP (alle organisasjoner, vår)
315
316**Meander Mobile App (MVP scope):**
317- Aktivitetsregistrering med lavest mulig antall klikk og standardverdier
318- WCAG 2.2 AA compliance fra dag én – for alle organisasjoner, uten unntak
319- E-post/passord innlogging (BankID/Vipps i fase 2)
320- Enkel statistikkvisning per likeperson og per koordinator
321- Kontaktliste og likepersonsoversikt
322- 2 mobilrolle-profiler: Peer Mentor, Coordinator (Organization Admins logger på som Coordinator i app-konteksten)
323
324**Admin Web Portal (MVP scope):**
325- Brukeradministrasjon (invitere, deaktivere, rolletildeling)
326- Organisasjonsinnstillinger og terminologikonfigurasjon
327- Aktivitetsoversikt og grunnleggende statistikk
328- 2 innloggede brukerroller: Organisasjonsadministrator, Global Administrator. Coordinators og Peer Mentors logger IKKE inn i admin-portalen; de forvaltes som datarecords (invitasjon, rolletildeling, deaktivering) av Org Admin.
329
330**Shared Backend (MVP scope):**
331- REST API (Next.js på Vercel) med standard relasjonsdatabase
332- JWT-basert autentisering
333- Flerorganisasjonsstøtte (multi-tenancy)
334
335**Product Sales Website (MVP scope):**
336- Statisk landingsside med produktbeskrivelse og fordeler
337- Enkelt demo-booking-skjema (sender til e-post/webhook, ingen pålogging)
338- Privacy policy og vilkår
339
340### Fase 2 – Kjerneprodukt
341
342- Bufdir-rapportering og eksport med ett klikk (kun i Admin Web Portal; mobilen bidrar med selve aktivitetsregistreringen)
343- Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning)
344- Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk)
345- Pausefunksjon og bulkregistrering for koordinatorer
346- Tale-til-tekst i rapportskriving
347- BankID / Vipps innlogging
348- Dokumentvedlegg til aktiviteter (NHF)
349- Koordinering med HLFs eksterne portalprosjekt
350
351### Fase 3 – Vekst og engasjement
352
353- Gamification / «Ditt likepersonsår» (Wrapped, badges, Advantage Calculator)
354- Kursadministrasjon og sertifisering (HLF + Barnekreftforeningen)
355- Formalisert rapportstruktur (Blindeforbundet + Barnekreftforeningen)
356- Regnskapsintegrasjon (Xledger for Blindeforbundet, Dynamics accounting for HLF)
357- Mentorordning / Career Workshops (Blindeforbundet)
358- Geografisk kartvisning (Blindeforbundet)
359- Snakkekort / Talking Cards Toolbox
360- Digitalt likepersonsbevis
361- Verving / Referral (HLF)
362
363### Fase 4 – Spekulativt (forskningsideer, ikke bekreftet)
364
365Ingen bekreftede Fase 4-leveranser. Fordelskalkulator (Advantage Calculator) ligger inne i Achievements & Gamification-området og følger derfor Fase 3.
366
367- Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov
368- Dokumentsignering innenfor Kryptert oppdragshåndtering
369- Spill og interaktive elementer
370- Stikk motsatt av likepersonslogg
371- Ny validering av value proposition for neste tenant-bølge
372
373## 6. Fellesåpne punkter
374
375- Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner.
376- Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering.
377- Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon.
378- Barnekreftforeningens unike behov (pårørende-database, formalisert rapportstruktur, kursadministrasjon) er nå inkludert i §3.4 og i prioriteringsmatrisen; ytterligere detaljer fra forprosjektet legges til ved behov.
379- Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell.
380
381## 7. Neste aksjonspunkter
382
383Fasene her følger samme nummerering som §5. Fase 0 er mobiliseringsfase (pre-utvikling). Fase 1–4 er utviklingsfaser.
384
385### Fase 0 – Mobilisering (frem til 13. mars)
386
387- Strategisk: Playing to win → Value prop (Alle)
388- Oppdatere pengecase (Daniel & Lasse)
389  - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler.
390- Kontakte Bufdir (Daniel)
391- Panorama
392- Få opp nettside (Aleksander)
393- Oversikt over hva vi har allerede utviklet (Marius og Aleksander)
394- Plan for pilotering/testing (Marius, Aleksander og Gellert)
395  - Featureoversikt
396  - Raskt ut og iterere basert på læring
397- Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert)
398
399### Fase 1 – MLP / MVP
400
401- Scope to be decided
402- Hva har vi allerede
403- Hva må på plass
404- Enkel admin
405- Mobil: aktivitetsregistrering, WCAG, enkel statistikk
406- Admin: brukeradministrasjon, organisasjonsinnstillinger, aktivitetsoversikt
407
408### Fase 2 – Kjerneprodukt
409
410- Bufdir-rapportering (eksport i admin)
411- Reiserefusjon
412- Pause
413- Bulkregistrering
414- Kryptert oppdragshåndtering (Blindeforbundet)
415- BankID / Vipps
416- Tale-til-tekst
417
418### Fase 3 – Vekst og engasjement
419
420- Gamification
421- Wrapped
422- Kursadministrasjon / sertifisering
423- Snakkekort / toolbox
424- Lenker til kurs
425- Digitalt likepersonsbevis
426- Validere value prop
427
428### Fase 4 – Spekulativt
429
430Ingen bekreftede Fase 4-leveranser. Fordelskalkulator følger Fase 3 via Achievements & Gamification-området.
431
432- Signering (videreutvikling av Kryptert oppdragshåndtering)
433- Spill
434- Stikk motsatt av likepersonlogg
435- Validere value prop på ny
436- Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov
437
438**Note:** Pårørende-database er Fase 1 MUST for Barnekreftforeningen (se §4 matrisen).
439
440---
441
442## 8. Vocabulary — Canonical Area & Feature Structure
443
444> **AUTHORITATIVE**: This section defines the official area names, feature groupings, and terminology for the Meander platform. The blueprint MUST use these exact area names and feature groupings. Do not invent new areas, merge areas, or move features between areas.
445>
446> **Dual role.** In this platform the area taxonomy also doubles as the module toggle registry — each Area ID is the unit that admins enable or disable per organization. Products reusing this pattern should preserve that 1:1 relationship (one area = one toggleable module). Products that don't need module toggles still benefit from the taxonomy as a stable vocabulary, but the toggle semantics become optional.
447>
448> **Bufdir split.** Bufdir reporting has two concerns: (a) data capture — handled by the mobile `activity-registration` area (activity logging produces the raw data Bufdir reports consume); and (b) report generation + export — handled exclusively by the admin `admin-reporting` area. The mobile app has no Bufdir-specific area; coordinators and peer mentors contribute data through normal activity registration, and organization admins run the report + export from the Admin Web Portal.
449>
450> **Sales Website exception.** The Sales Website areas below exist for organizational clarity of the source doc, but the Sales Website is a static information site and does **not** participate in the module toggle system. Its areas are not toggled per tenant.
451>
452> **Shared areas, org-specific meaning.** An area can be enabled by multiple tenants who use it for materially different workflows. Example: `certification-training` → for HLF it's formal course registration + certification renewal (regulated); for Barnekreftforeningen it's onboarding and follow-up courses for new peer mentors; for Blindeforbundet "Career Workshops" means mentor-led two-day group sessions for mentees. The area is the same toggle; the content, labels, and workflows inside it vary by org configuration + the Organization Labels system. Do not split the area just because tenants use it differently — split only when the UI/API/admin surfaces genuinely diverge.
453
454### Mobile App — Areas
455
456| Area ID | Area Name | Features |
457|-|-|-|
458| authentication-access-control | Authentication & Access Control | Email & Password Login, BankID Authentication, Vipps Authentication, Biometric Login (Face ID/Fingerprint), Passkeys (WebAuthn), Role-Based Access Control |
459| profile-management | Profile Management | Profile Data & Settings, Profile Switching |
460| activity-registration | Activity Registration | Simple Activity Logging, Activity Registration Wizard, Calendar Sync, Speech-to-Text Input, Document Attachments, Formalized Home-Visit Report |
461| proxy-bulk-registration | Proxy & Bulk Registration | Coordinator Proxy Reporting, Bulk Registration |
462| event-management | Event Management | Event Creation, Event Listing, Event Sign-up |
463| expense-reimbursement | Expense & Reimbursement | Travel Expense Registration, Receipt Photo Upload, Expense Types & Requirements, Confidentiality Declarations |
464| contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin |
465| notes | Notes | Notes List, Note Editor |
466| statistics | Statistics | Personal Activity Statistics, Coordinator Team Reports |
467| encrypted-assignments | Encrypted Data Assignments | Encrypted Assignment Dispatch, Assignment Threshold Tracking, Progressive Digital Consent |
468| relatives-database | Relatives Database | Relative Contact Registration, Relative Case Linking, Relative Role Tagging |
469| peer-mentor-status | Peer Mentor Status | Pause Function, Resume Function, Certification Expiry Auto-Pause |
470| geographic-map-view | Geographic Map View | Peer Mentor Map, Assignment Matching by Geography |
471| mentor-program | Mentor Program | Career Workshops, Workshop Notes, Workshop Participant Lists, Workshop To-Do Lists |
472| notifications | Notifications | Push Notifications, Email/SMS Notifications, Notification Scenarios, Notification Settings |
473| referral-program | Referral Program | Invite Link & QR Sharing, Recruitment Tracking |
474| certification-training | Certification & Training | Course Registration, Digital Peer Mentor Certificate, Certificate Renewal Reminder |
475| achievements-gamification | Achievements & Gamification | Annual Summary (Wrapped), Achievement Badges, Advantage Calculator |
476| conversation-tools | Conversation Tools | Talking Cards Toolbox |
477| accessibility | Accessibility | WCAG 2.2 AA Compliance, Sensitive Field Readout Warning |
478| home-navigation | Home & Navigation | Role-Specific Home Dashboard, App Settings & Preferences, External Resource Links |
479| help-support | Help & Support | Contact Us, Privacy Policy, Accessibility Statement, FAQ |
480| offline-sync | Offline & Sync | Offline Data Support, Background Sync |
481
482### Admin Portal — Areas
483
484| Area ID | Area Name | Features |
485|-|-|-|
486| admin-dashboard | Admin Dashboard | Dashboard KPIs, Activity Feed |
487| admin-user-management | User Management | User CRUD, Role Assignment, Bulk Actions |
488| admin-activity-oversight | Activity Oversight | Activity Review & Approval, Activity Flagging, Duplicate Activity Detection |
489| admin-expense-approval | Expense Approval | Expense Approval Queue, Auto-Approval Rules, Reimbursement Overview |
490| admin-reporting | Reporting & Export | Team Reports, Bufdir Report Generation, Bufdir Export, Custom Reports |
491| admin-organization | Organization Management | Organization Settings, Custom Terminology, Feature Toggles, Multi-Organization Hierarchy, Member Associations, External Portal Integration (HLF config flag) |
492| admin-accounting | Accounting Integration | Accounting API, Accounting Export |
493| admin-security | Security & Audit | Security Dashboard, Audit Log, Session Management |
494
495### Sales Website — Areas
496
497| Area ID | Area Name | Features |
498|-|-|-|
499| sales-product | Product Showcase | Product Landing Page, Feature Overview |
500| sales-calculator | Benefit Calculator | Impact Calculator, Cost Comparison |
501| sales-demo | Demo Booking | Booking Form, Booking Confirmation |
502| sales-legal | Legal Documents | Privacy Policy, Terms of Service, DPA, Cookie Policy |
503
504### Terminology
505
506| Term | Definition | Norwegian |
507|-|-|-|
508| Peer Mentor | Volunteer who provides support to contacts | Likeperson |
509| Coordinator | Staff member who manages peer mentors | Koordinator |
510| Organization Admin | Administrator of a single organization | Organisasjonsadministrator |
511| Global Admin | Administrator across all organizations | Global administrator |
512| Contact | Person receiving support from a peer mentor | Kontakt (overrideable per org via the Organization Labels system, e.g. `Familie`, `Bruker`) |
513| Activity | A logged interaction (home visit, phone call, meeting, etc.) | Aktivitet |
514| Assignment | Encrypted sensitive data dispatch to a peer mentor | Oppdrag |
515| Reimbursement | Expense claim for travel or other costs | Refusjon / Utlegg |
516| Bufdir | Norwegian government agency funding the program | Bufdir |
517| Area | High-level functional grouping in the platform | Omrade |
518| Feature | Specific capability within an area | Funksjon |
519

# Tverrgående workshopsammendrag ## Behovskartlegging – Likepersonsapp **Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen, Norse Test Organization** **Version 7.0.0** Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund, Hørselsforbundet (HLF), Barnekreftforeningen og Norse Test Organization. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling. > **Note on reuse.** Parts of this document describe patterns (module toggles, area taxonomy, decoupled auth module, organization labels) that are specific to *this* platform's multi-tenant, multi-organization shape. Other products generated from a source doc via the same pipeline will not necessarily share that shape — a single-tenant SaaS, an internal tool, or a fixed-scope deliverable typically should **not** adopt module toggles or per-tenant label overrides. Each architectural pattern below is scoped with an applicability note; treat them as options justified by stated constraints, not defaults. ## 1. Felles behov – går igjen i alle fire organisasjoner Følgende behov ble løftet frem – ofte ord for ord – i alle workshops. Dette er kjernen i hva appen MÅ løse. ### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle) Alle fire organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller. - **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk. - **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst. - **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle. > **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg. ### 1.2 Universell utforming (WCAG 2.2 AA) Alle fire organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner – fra dag én, for alle organisasjoner. Ingen organisasjon er unntatt eller utsatt til senere fase. - **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå. - **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle. - **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning. - **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter. - **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size). - **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator. - Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen. - Varsling ved opplesning av sensitive felt (NHF). - **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements). ### 1.3 BankID / Vipps innlogging Alle fire organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. **MVP leveres med e-post/passord-innlogging; BankID og Vipps ruller ut i Fase 2** (se §5 og prioriteringsmatrisen i §4). Denne seksjonen beskriver den langsiktige foretrukne tilstanden, ikke MVP-scopet. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere. ### 1.4 Sømløs Bufdir-rapportering Alle fire organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. **Rapporteringsdata samles inn gjennom aktivitetsregistrering i mobilappen**, men **selve Bufdir-eksporten er en admin-funksjon**: organisasjonsadministrator kjører eksporten fra Admin Web Portal. Koordinatorer og likepersoner logger kun inn på mobilappen og har dermed ikke tilgang til eksportfunksjonen. Mobilappen har ikke Bufdir-eksport som funksjon – kun registrering. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene. ### 1.5 Inkrementell utrulling – parallelle systemer Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg. - **NHF:** «Ikke steng det gamle før folk er klare.» - **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side. - **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling. ### 1.6 Testoppsett: TestFlight (iOS) + Apptester (Android), 5–8 personer, én kontaktperson Alle fire organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight og Android-distribusjon via Apptester på lik linje, 5–8 testpersoner per plattform med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren. ## 2. Delte behov – nevnt av to eller flere organisasjoner Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt. Det autoritative per-org-bildet er prioriteringsmatrisen i §4 – narrativet her forklarer mønsteret bak. ### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet) Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav: - Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett). - Kvitteringsbilde for utlegg over 100 kr (HLF). - Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF). - Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet). - API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF). ### 2.2 Gamification og synliggjøring av innsats (NHF + HLF + Barnekreftforeningen) Tre organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer. Blindeforbundet har ikke samme behov og ser det som mindre relevant. ### 2.3 Pausefunksjon for likepersoner (NHF + HLF + Barnekreftforeningen) Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk. Blindeforbundet håndterer dette manuelt og har ikke fremhevet behovet. ### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF + Barnekreftforeningen) Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere). Blindeforbundet bruker ikke proxy-rapportering på samme måte og prioriterer dette lavt. ### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF) Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving. ## 3. Unike behov per organisasjon ### 3.1 Norges Blindeforbund – unike behov - **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag. - Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet. - **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15. - **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren. - Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale. - **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker). - **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager. - Gradvis digitalisering av fullmakter og epikriser med manuelt fallback. ### 3.2 Norges Handikapforbund – unike behov - **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne. - **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering. - **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer. - **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving. - **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes. ### 3.3 Hørselsforbundet – unike behov - **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel. - **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt. (Barnekreftforeningen har et beslektet behov og er også markert i matrisen.) - **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre. - **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering. - **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel). ### 3.4 Barnekreftforeningen – unike behov - **Pårørende-database:** Barnekreftforeningen jobber primært med familier rundt barn med kreft, ikke kun med de berørte selv. Appen må støtte registrering av pårørende (foreldre, søsken, nærmeste omsorgsperson) som egne kontaktsubjekter knyttet til samme sak. - **Formalisert rapportstruktur** (delt med Blindeforbundet): kort strukturert etterrapport etter hjemmebesøk eller samtale, som fungerer som bestilling til koordinator. - **Kursadministrasjon** (delt med HLF) for opplæring av nye likepersoner og oppfølgingskurs. - Øvrige fellesbehov (bulkregistrering, pausefunksjon, gamification) er beskrevet i §2 – Barnekreftforeningen inngår der også. ### 3.5 Norse Test Organization – unike behov Norse Test Organization er en intern testorganisasjon opprettet av Norse Digital Products for å validere hele plattformen end-to-end med full moduldekning. Den er ikke en reell kundeklient, men representerer en tenkt organisasjon som har aktivert alle tilgjengelige moduler og funksjoner. - **Full modulaktivering:** Alle togglable moduler er aktivert — inkludert expense-reimbursement, encrypted-assignments, certification-training, achievements-gamification, geographic-map-view, mentor-program, relatives-database, referral-program og alle øvrige. - **Testformål:** Sikre at kombinasjonen av alle aktiverte moduler ikke gir konflikter i navigasjon, API-respons, eller admin-portal. - **Alle matrisefunksjoner:** Norse Test er eneste organisasjon med ✓ på absolutt alle behovspunkter i §4-matrisen. - **Ingen organisasjonsspesifikke begrensninger:** Terminologi, labels og config-flagg er satt til standardverdier for å unngå at org-spesifikke overrides skjuler feil i standardoppsett. - **Brukes ikke i produksjon:** Data generert av Norse Test-organisasjonen er testdata og skal ikke inngå i Bufdir-rapportering eller øvrig ekstern rapportering. ## 4. Behovsoversikt – prioriteringsmatrise > **How to read this matrix.** It is a workshop snapshot of divergent stakeholder needs — the input that motivated the module-toggle architecture below. It is **not** a development spec and should not drive per-organization code branches. Authoritative per-org scope lives in the module toggle registry (see *Module Toggles per Organization*). The Prioritet and Fase columns are indicative only; the current roadmap lives in sections 5 and 7 and will drift as priorities shift. | Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Norse Test | Prioritet | Fase | |-|-|-|-|-|-|-|-| | Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Universell utforming / tilgjengelighet (WCAG 2.2 AA) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 | | Bufdir-rapportering (eksport, admin) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 | | Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | TestFlight (iOS) + Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 | | Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | ✓ | NICE TO HAVE | 3 | | Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 | | Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 | | Tale-til-tekst | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 | | Kryptert oppdragshåndtering | – | – | ✓ | – | ✓ | MUST (Blindeforbundet) | 2 | | Formalisert rapportstruktur | ✓ | – | ✓ | – | ✓ | NICE (Blind. + Barnekreft) | 3 | | Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | ✓ | SHOULD (HLF + Barnekreft) | 3 | | Koordinering med ekstern portal | – | – | – | ✓ | ✓ | MUST (HLF) | 2 | | Dokumentvedlegg til aktiviteter | – | ✓ | – | – | ✓ | NICE TO HAVE | 2 | | Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Snakkekort | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 3 | | Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 | | Pårørende database | ✓ | – | – | – | ✓ | MUST (Barnekreft) | 1 | | Basic search (contact og notater) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST | 1 | | Notater | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 | | Verving / Referral (invite-link, rekruttering) | – | – | – | ✓ | ✓ | SHOULD (HLF) | 3 | ### Product Landscape — Meander Platform Meander is the platform. It ships as four distinct products, each serving different users and purposes. The **two operational products** (Mobile App + Admin Web Portal) share the same database and the same authentication module. The Authentication Module is a decouplable service shared by them. The Sales Website is a separate public information site with no auth, no database access, and no shared runtime — it only links out to marketing content. **Product 1: Meander Mobile App** (Flutter) - Purpose: Day-to-day operational tool for peer mentors and coordinators - Users: Peer Mentors (Likepersoner), Coordinators (Organization Admins appear as Coordinators on mobile) - Core capabilities (always available): - Activity registration (quick logging, wizards, bulk/proxy) - Contact and peer mentor management - Personal statistics and impact summaries - Push notifications and assignment tracking - Optional capabilities (toggled per organization): - Travel expense registration (`expense-reimbursement`) - Speech-to-text input (config flag on `activity-registration`) - Document attachments to activities - Gamification — wrapped summaries, badges (`achievements-gamification`) - Encrypted assignments (`encrypted-assignments`) - Course registration & certification (`certification-training`) - Tech: Flutter, Riverpod (no codegen), Drift (offline), WCAG 2.2 AA **Product 2: Admin Web Portal** (Next.js) - Purpose: Organization management, reporting, and oversight - Logged-in users: Organization Admins, Global Admins. Coordinators and Peer Mentors are **managed** inside the admin portal (invitations, role assignment, deactivation) but never log in to it — they only log in to the Mobile App. - Core capabilities: - User management (invite, deactivate, role assignment) - Organization settings and terminology/labels configuration - Bufdir report generation and one-click export - Activity oversight, approval workflows, and corrections - Reimbursement approval and expense oversight - Coordinator and organization-level dashboards and KPIs - Multi-organization hierarchy management - Course and certification administration - Tech: Next.js on Vercel, server-side rendering, same auth system **Product 3: Authentication Module** - Purpose: Issue and validate credentials for every Meander product. Treated as its own product — not a feature of any single product — because it must be decouplable and movable into its own service or repository at any time without forcing changes on consumers. - Users: Every other Meander product that needs to know who a user is: Mobile App, Admin Web Portal, and any future product, partner, or integration. - Core capabilities: - Email/password sign-in for MVP; BankID and Vipps in Phase 2 - Short-lived access tokens plus rotating refresh tokens - Session revocation (sign-out, forced expiry, admin-initiated) - Per-tenant isolation of signing material - A clean extension point for attaching product-specific claims (role, organization memberships) without the auth module knowing the product's schema - Boundaries: - Owns only identity and session state. No product data, no authorization logic, no role semantics. - Authorization (who can do what within a product, tenant scoping, audit of domain actions) is the consuming product's responsibility. - Exposes a stable contract (sign-in, sign-out, refresh, identity lookup) so consumers do not depend on its internals. - Portability requirement: the module must be extractable into a standalone service or repository later without API changes for consumers. This rules out reaching into product tables, coupling to product frameworks, or leaking product concepts into tokens beyond a generic claims bag. **Product 4: Product Sales Website** (simple static site) - Purpose: Public information site for prospective organizations — explains what Meander is, shows features, and collects demo requests. - Users: Prospective organizations, buyers, decision-makers - Scope: **Information-only.** No authentication, no user accounts, no database, no shared runtime with the operational products. A demo-request form may POST to a lightweight form handler (email/webhook), but nothing more. - Core capabilities: - Product landing page and feature overview - Benefit / impact calculator (static calculation, no login) - Demo booking form - Privacy policy, Terms of Service, Data Processing Agreement, Cookie Policy - Tech: Static site (Next.js static export, Astro, or plain HTML/CSS). Public-facing, no auth, no backend dependency. ### Module Toggles per Organization > **Applicability.** This pattern applies to multi-tenant products whose tenants have materially divergent needs (the Meander case: four organizations with partly overlapping feature sets). Single-tenant products, or products where every tenant uses the same feature set, do **not** need module toggles — the added config surface is overhead without benefit. When adopting this pattern from a source doc into a new product, first confirm the tenancy and divergence actually justify it. Not every organization needs every capability. The needs matrix shows features that are must-have for one organization and irrelevant for another (e.g. encrypted assignments for Blindeforbundet, course administration for HLF, document attachments for NHF). Rather than branching the product per organization, the platform treats each functional area as an independently toggleable module. **Design intent:** - **Module = Area.** The canonical areas defined in the area taxonomy (section 8) are the unit of toggling. Each area ID (e.g. `expense-reimbursement`, `encrypted-assignments`, `certification-training`) is a module that can be enabled or disabled per tenant. This keeps the registry generic — no hand-maintained feature flag list parallel to the area taxonomy. - **Admin surface owns the switch.** Whichever product serves as the administrative surface (here, the Admin Web Portal) exposes the toggles under Organization Management → Feature Toggles. The enabled set is persisted as tenant configuration. - **Backend is the source of truth.** The API exposes the enabled module set for the current user's tenant as part of the session/bootstrap response. Every endpoint that belongs to a module checks the tenant's enabled set before executing — clients cannot bypass a disabled module by calling the API directly. - **Clients load generically.** Clients (mobile, web, partner integrations) do not hardcode which tabs, entry points, or screens exist. At startup each client reads the enabled module set and renders only the navigation, surfaces, and flows belonging to enabled modules. Disabling a module hides its UI entirely; re-enabling restores it without a client release. - **Always-on core.** A small set of modules is non-toggleable because the operational products are meaningless without them. Each operational product has its own always-on set: - **Mobile App:** `authentication-access-control`, `home-navigation`, `accessibility`, `help-support`, `profile-management`. - **Admin Web Portal:** `admin-dashboard`, `admin-user-management`, `admin-organization`, `admin-security`. `admin-organization` is always-on because it hosts the Feature Toggles UI itself — disabling it would remove the only place toggles can be re-enabled (circular dependency). - The Sales Website is out of scope for module toggles entirely — it is a static information site with no module concept. - Other products reusing this pattern should define their own always-on set based on what is universally required and which module (if any) hosts the toggle-management UI. - **Dependencies between modules** are declared in the registry, not inferred. If module A requires module B, enabling A implicitly enables B; the admin UI makes this visible rather than failing silently at runtime. - **Area toggle vs config flag.** Toggle a whole area when the full workflow (UI, API, admin tooling) appears or disappears together. Use a config flag inside an area when only one dimension varies (e.g. speech-to-text on `activity-registration`, receipt-required threshold inside `expense-reimbursement`). Prefer the lighter option; promote a config flag to its own area only when a second tenant actually diverges. - **No per-tenant code paths.** Tenant-specific behavior lives in (a) the enabled module set, (b) a terminology/labels system for display strings, and (c) per-module configuration values. New tenants onboard by picking modules and labels, never by shipping code. This keeps the codebase single-tenant in shape while supporting multiple organizations with materially different needs, and leaves room for new tenants without a rewrite. ### Core Roles & Access Boundaries Each organization has its own roles and users. Norse (the platform owner) manages global admins separately. **4 defined user roles:** - **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Logs in to the Mobile App only. Beginner-level digital skills assumed. Managed (invited, assigned, deactivated) by Org Admin from the admin portal, but does not log in to the admin portal. - **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Logs in to the Mobile App only. Like Peer Mentors, Coordinators are managed from the admin portal by Org Admin but do not have admin portal login access. - **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Logs in to the admin portal (primary surface). **On mobile, an Org Admin is surfaced as a Coordinator** — they use the same mobile experience as coordinators without a separate UI path. Admin-only capabilities (user management, reports, toggles) live exclusively in the admin portal. - **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. **No default access to an organization's operational data (users, activities, contacts).** Tenant separation is strict: each org's data is isolated. Orgs can grant a Global Admin *time-bounded* support access via a flag in Organization Settings (e.g. "Allow Norse support access until {date}"); revoking the flag or hitting the expiry immediately removes access. Every support-access session is logged in the org's audit trail. ### Core Operational Flow 1. Peer mentor performs activity or event 2. Activity is registered and tracked in Meander Mobile App 3. Coordinator oversees follow-up, quality, and approval 4. Org Admin gets overview in Admin Web Portal 5. Structured data supports Bufdir reporting and analytics ### Shared Backend Shared only by the **operational products** (Mobile App + Admin Web Portal). The Sales Website does not touch this backend. - **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`) - **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR) - **Database** (standard relational, managed) — no vendor-specific extensions, pure SQL with migrations - **Authentication:** Handled by the Authentication Module (Product 3), treated as a decoupled product so it can be moved into its own service or repository later without forcing changes on consumers. Issues short-lived access tokens plus rotating refresh tokens; sessions survive silently across token expiry and end cleanly when the refresh chain is broken. Email/password for MVP; BankID/Vipps in Phase 2. Biometric session unlock (Face ID / fingerprint) after first login. Mobile stores tokens in the platform secure store; admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context). Authorization — roles, organization scoping, tenant isolation — is the consuming product's responsibility, never the auth module's. ### Mobile App Architecture **Auth & Access** - **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login. - Email/password login - BankID / Vipps login (Phase 2) - Biometric session authentication (Face ID / fingerprint) - Role-based access control — Peer Mentor and Coordinator roles - No-access screen for Global Admin (redirected to admin portal) **Navigation** - Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications - Settings accessible from hamburger menu **Screens** - Role-specific home content (peer mentor vs coordinator variants) - Contacts list with role-specific views - Contact detail, edit, and peer mentor profile screens - Activity wizard (multi-step: contact → date → time → duration → summary) - Event wizard (multi-step: title → date → time → duration → location → summary) - Settings and preferences - Notification inbox **Core/Shared** - REST API client (`ApiHttpClient`) with JWT bearer, auto-refresh on 401, 15s timeout, and a typed `ApiException` hierarchy - Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver) - Optimistic mutations with automatic rollback on failure (contact edits and paginated list updates) - Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant - Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table - Organization labels system — per-org terminology overrides fetched from backend and cached offline (currently: `contacts`, `my_contacts`, `peer_mentors`; extensible to singular forms and role terms such as `peer_mentor`, `coordinator`, `contact`) - Module registry — the app's navigation, home surfaces, and entry points are assembled at runtime from the enabled module set returned by the backend. Each area from section 8 registers its nav item, home widgets, and deep links against its area ID; disabled modules are simply not mounted. No compile-time switching per organization. ## 5. Anbefalt prioriteringsrekkefølge for teamet Fasene her speiler aksjonspunktene i §7. Fase 0 er mobiliseringsfasen (pre-utvikling) og er beskrevet i §7. Fase 1–4 nedenfor er utviklingsfasene. ### Fase 1 – MVP (alle organisasjoner, vår) **Meander Mobile App (MVP scope):** - Aktivitetsregistrering med lavest mulig antall klikk og standardverdier - WCAG 2.2 AA compliance fra dag én – for alle organisasjoner, uten unntak - E-post/passord innlogging (BankID/Vipps i fase 2) - Enkel statistikkvisning per likeperson og per koordinator - Kontaktliste og likepersonsoversikt - 2 mobilrolle-profiler: Peer Mentor, Coordinator (Organization Admins logger på som Coordinator i app-konteksten) **Admin Web Portal (MVP scope):** - Brukeradministrasjon (invitere, deaktivere, rolletildeling) - Organisasjonsinnstillinger og terminologikonfigurasjon - Aktivitetsoversikt og grunnleggende statistikk - 2 innloggede brukerroller: Organisasjonsadministrator, Global Administrator. Coordinators og Peer Mentors logger IKKE inn i admin-portalen; de forvaltes som datarecords (invitasjon, rolletildeling, deaktivering) av Org Admin. **Shared Backend (MVP scope):** - REST API (Next.js på Vercel) med standard relasjonsdatabase - JWT-basert autentisering - Flerorganisasjonsstøtte (multi-tenancy) **Product Sales Website (MVP scope):** - Statisk landingsside med produktbeskrivelse og fordeler - Enkelt demo-booking-skjema (sender til e-post/webhook, ingen pålogging) - Privacy policy og vilkår ### Fase 2 – Kjerneprodukt - Bufdir-rapportering og eksport med ett klikk (kun i Admin Web Portal; mobilen bidrar med selve aktivitetsregistreringen) - Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning) - Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk) - Pausefunksjon og bulkregistrering for koordinatorer - Tale-til-tekst i rapportskriving - BankID / Vipps innlogging - Dokumentvedlegg til aktiviteter (NHF) - Koordinering med HLFs eksterne portalprosjekt ### Fase 3 – Vekst og engasjement - Gamification / «Ditt likepersonsår» (Wrapped, badges, Advantage Calculator) - Kursadministrasjon og sertifisering (HLF + Barnekreftforeningen) - Formalisert rapportstruktur (Blindeforbundet + Barnekreftforeningen) - Regnskapsintegrasjon (Xledger for Blindeforbundet, Dynamics accounting for HLF) - Mentorordning / Career Workshops (Blindeforbundet) - Geografisk kartvisning (Blindeforbundet) - Snakkekort / Talking Cards Toolbox - Digitalt likepersonsbevis - Verving / Referral (HLF) ### Fase 4 – Spekulativt (forskningsideer, ikke bekreftet) Ingen bekreftede Fase 4-leveranser. Fordelskalkulator (Advantage Calculator) ligger inne i Achievements & Gamification-området og følger derfor Fase 3. - Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov - Dokumentsignering innenfor Kryptert oppdragshåndtering - Spill og interaktive elementer - Stikk motsatt av likepersonslogg - Ny validering av value proposition for neste tenant-bølge ## 6. Fellesåpne punkter - Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner. - Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering. - Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon. - Barnekreftforeningens unike behov (pårørende-database, formalisert rapportstruktur, kursadministrasjon) er nå inkludert i §3.4 og i prioriteringsmatrisen; ytterligere detaljer fra forprosjektet legges til ved behov. - Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell. ## 7. Neste aksjonspunkter Fasene her følger samme nummerering som §5. Fase 0 er mobiliseringsfase (pre-utvikling). Fase 1–4 er utviklingsfaser. ### Fase 0 – Mobilisering (frem til 13. mars) - Strategisk: Playing to win → Value prop (Alle) - Oppdatere pengecase (Daniel & Lasse) - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler. - Kontakte Bufdir (Daniel) - Panorama - Få opp nettside (Aleksander) - Oversikt over hva vi har allerede utviklet (Marius og Aleksander) - Plan for pilotering/testing (Marius, Aleksander og Gellert) - Featureoversikt - Raskt ut og iterere basert på læring - Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert) ### Fase 1 – MLP / MVP - Scope to be decided - Hva har vi allerede - Hva må på plass - Enkel admin - Mobil: aktivitetsregistrering, WCAG, enkel statistikk - Admin: brukeradministrasjon, organisasjonsinnstillinger, aktivitetsoversikt ### Fase 2 – Kjerneprodukt - Bufdir-rapportering (eksport i admin) - Reiserefusjon - Pause - Bulkregistrering - Kryptert oppdragshåndtering (Blindeforbundet) - BankID / Vipps - Tale-til-tekst ### Fase 3 – Vekst og engasjement - Gamification - Wrapped - Kursadministrasjon / sertifisering - Snakkekort / toolbox - Lenker til kurs - Digitalt likepersonsbevis - Validere value prop ### Fase 4 – Spekulativt Ingen bekreftede Fase 4-leveranser. Fordelskalkulator følger Fase 3 via Achievements & Gamification-området. - Signering (videreutvikling av Kryptert oppdragshåndtering) - Spill - Stikk motsatt av likepersonlogg - Validere value prop på ny - Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov **Note:** Pårørende-database er Fase 1 MUST for Barnekreftforeningen (se §4 matrisen). --- ## 8. Vocabulary — Canonical Area & Feature Structure > **AUTHORITATIVE**: This section defines the official area names, feature groupings, and terminology for the Meander platform. The blueprint MUST use these exact area names and feature groupings. Do not invent new areas, merge areas, or move features between areas. > > **Dual role.** In this platform the area taxonomy also doubles as the module toggle registry — each Area ID is the unit that admins enable or disable per organization. Products reusing this pattern should preserve that 1:1 relationship (one area = one toggleable module). Products that don't need module toggles still benefit from the taxonomy as a stable vocabulary, but the toggle semantics become optional. > > **Bufdir split.** Bufdir reporting has two concerns: (a) data capture — handled by the mobile `activity-registration` area (activity logging produces the raw data Bufdir reports consume); and (b) report generation + export — handled exclusively by the admin `admin-reporting` area. The mobile app has no Bufdir-specific area; coordinators and peer mentors contribute data through normal activity registration, and organization admins run the report + export from the Admin Web Portal. > > **Sales Website exception.** The Sales Website areas below exist for organizational clarity of the source doc, but the Sales Website is a static information site and does **not** participate in the module toggle system. Its areas are not toggled per tenant. > > **Shared areas, org-specific meaning.** An area can be enabled by multiple tenants who use it for materially different workflows. Example: `certification-training` → for HLF it's formal course registration + certification renewal (regulated); for Barnekreftforeningen it's onboarding and follow-up courses for new peer mentors; for Blindeforbundet "Career Workshops" means mentor-led two-day group sessions for mentees. The area is the same toggle; the content, labels, and workflows inside it vary by org configuration + the Organization Labels system. Do not split the area just because tenants use it differently — split only when the UI/API/admin surfaces genuinely diverge. ### Mobile App — Areas | Area ID | Area Name | Features | |-|-|-| | authentication-access-control | Authentication & Access Control | Email & Password Login, BankID Authentication, Vipps Authentication, Biometric Login (Face ID/Fingerprint), Passkeys (WebAuthn), Role-Based Access Control | | profile-management | Profile Management | Profile Data & Settings, Profile Switching | | activity-registration | Activity Registration | Simple Activity Logging, Activity Registration Wizard, Calendar Sync, Speech-to-Text Input, Document Attachments, Formalized Home-Visit Report | | proxy-bulk-registration | Proxy & Bulk Registration | Coordinator Proxy Reporting, Bulk Registration | | event-management | Event Management | Event Creation, Event Listing, Event Sign-up | | expense-reimbursement | Expense & Reimbursement | Travel Expense Registration, Receipt Photo Upload, Expense Types & Requirements, Confidentiality Declarations | | contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin | | notes | Notes | Notes List, Note Editor | | statistics | Statistics | Personal Activity Statistics, Coordinator Team Reports | | encrypted-assignments | Encrypted Data Assignments | Encrypted Assignment Dispatch, Assignment Threshold Tracking, Progressive Digital Consent | | relatives-database | Relatives Database | Relative Contact Registration, Relative Case Linking, Relative Role Tagging | | peer-mentor-status | Peer Mentor Status | Pause Function, Resume Function, Certification Expiry Auto-Pause | | geographic-map-view | Geographic Map View | Peer Mentor Map, Assignment Matching by Geography | | mentor-program | Mentor Program | Career Workshops, Workshop Notes, Workshop Participant Lists, Workshop To-Do Lists | | notifications | Notifications | Push Notifications, Email/SMS Notifications, Notification Scenarios, Notification Settings | | referral-program | Referral Program | Invite Link & QR Sharing, Recruitment Tracking | | certification-training | Certification & Training | Course Registration, Digital Peer Mentor Certificate, Certificate Renewal Reminder | | achievements-gamification | Achievements & Gamification | Annual Summary (Wrapped), Achievement Badges, Advantage Calculator | | conversation-tools | Conversation Tools | Talking Cards Toolbox | | accessibility | Accessibility | WCAG 2.2 AA Compliance, Sensitive Field Readout Warning | | home-navigation | Home & Navigation | Role-Specific Home Dashboard, App Settings & Preferences, External Resource Links | | help-support | Help & Support | Contact Us, Privacy Policy, Accessibility Statement, FAQ | | offline-sync | Offline & Sync | Offline Data Support, Background Sync | ### Admin Portal — Areas | Area ID | Area Name | Features | |-|-|-| | admin-dashboard | Admin Dashboard | Dashboard KPIs, Activity Feed | | admin-user-management | User Management | User CRUD, Role Assignment, Bulk Actions | | admin-activity-oversight | Activity Oversight | Activity Review & Approval, Activity Flagging, Duplicate Activity Detection | | admin-expense-approval | Expense Approval | Expense Approval Queue, Auto-Approval Rules, Reimbursement Overview | | admin-reporting | Reporting & Export | Team Reports, Bufdir Report Generation, Bufdir Export, Custom Reports | | admin-organization | Organization Management | Organization Settings, Custom Terminology, Feature Toggles, Multi-Organization Hierarchy, Member Associations, External Portal Integration (HLF config flag) | | admin-accounting | Accounting Integration | Accounting API, Accounting Export | | admin-security | Security & Audit | Security Dashboard, Audit Log, Session Management | ### Sales Website — Areas | Area ID | Area Name | Features | |-|-|-| | sales-product | Product Showcase | Product Landing Page, Feature Overview | | sales-calculator | Benefit Calculator | Impact Calculator, Cost Comparison | | sales-demo | Demo Booking | Booking Form, Booking Confirmation | | sales-legal | Legal Documents | Privacy Policy, Terms of Service, DPA, Cookie Policy | ### Terminology | Term | Definition | Norwegian | |-|-|-| | Peer Mentor | Volunteer who provides support to contacts | Likeperson | | Coordinator | Staff member who manages peer mentors | Koordinator | | Organization Admin | Administrator of a single organization | Organisasjonsadministrator | | Global Admin | Administrator across all organizations | Global administrator | | Contact | Person receiving support from a peer mentor | Kontakt (overrideable per org via the Organization Labels system, e.g. `Familie`, `Bruker`) | | Activity | A logged interaction (home visit, phone call, meeting, etc.) | Aktivitet | | Assignment | Encrypted sensitive data dispatch to a peer mentor | Oppdrag | | Reimbursement | Expense claim for travel or other costs | Refusjon / Utlegg | | Bufdir | Norwegian government agency funding the program | Bufdir | | Area | High-level functional grouping in the platform | Omrade | | Feature | Specific capability within an area | Funksjon |