likeperson.md

1# Tverrgående workshopsammendrag

2## Behovskartlegging – Likepersonsapp

3**Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen, Norse Test Organization**

4**Version 8.0.0**

5Dette 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.

6> **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.

7## 1. Felles behov – går igjen i alle fire organisasjoner

8Følgende behov ble løftet frem – ofte ord for ord – i alle workshops. Dette er kjernen i hva appen MÅ løse.

9### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle)

10Alle 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.

11- **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk.

12- **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst.

13- **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.

14> **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg.

15### 1.2 Universell utforming (WCAG 2.2 AA)

16Alle 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.

17- **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå.

18- **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle.

19- **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning.

20- **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.

21- **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size).

22- **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator.

23- Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen.

24- Varsling ved opplesning av sensitive felt (NHF).

25- **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements).

26### 1.3 BankID / Vipps innlogging

27Alle 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.

28### 1.4 Sømløs Bufdir-rapportering

29Alle 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.

30### 1.5 Inkrementell utrulling – parallelle systemer

31Sterk 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.

32- **NHF:** «Ikke steng det gamle før folk er klare.»

33- **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side.

34- **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling.

35### 1.6 Testoppsett: TestFlight (iOS) + Apptester (Android), 5–8 personer, én kontaktperson

36Alle 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.

37## 2. Delte behov – nevnt av to eller flere organisasjoner

38Disse 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.

39### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet)

40Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav:

41- Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett).

42- Kvitteringsbilde for utlegg over 100 kr (HLF).

43- Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF).

44- Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet).

45- API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF).

46### 2.2 Gamification og synliggjøring av innsats (NHF + HLF + Barnekreftforeningen)

47Tre 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.

48### 2.3 Pausefunksjon for likepersoner (NHF + HLF + Barnekreftforeningen)

49Likepersoner 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.

50### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF + Barnekreftforeningen)

51Ikke 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.

52### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF)

53Begge 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.

54## 3. Unike behov per organisasjon

55### 3.1 Norges Blindeforbund – unike behov

56- **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag.

57- Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet.

58- **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15.

59- **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren.

60- Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale.

61- **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker).

62- **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager.

63- Gradvis digitalisering av fullmakter og epikriser med manuelt fallback.

64### 3.2 Norges Handikapforbund – unike behov

65- **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne.

66- **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering.

67- **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer.

68- **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving.

69- **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes.

70### 3.3 Hørselsforbundet – unike behov

71- **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel.

72- **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.)

73- **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre.

74- **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering.

75- **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel).

76### 3.4 Barnekreftforeningen – unike behov

77- **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.

78- **Formalisert rapportstruktur** (delt med Blindeforbundet): kort strukturert etterrapport etter hjemmebesøk eller samtale, som fungerer som bestilling til koordinator.

79- **Kursadministrasjon** (delt med HLF) for opplæring av nye likepersoner og oppfølgingskurs.

80- Øvrige fellesbehov (bulkregistrering, pausefunksjon, gamification) er beskrevet i §2 – Barnekreftforeningen inngår der også.

81### 3.5 Norse Test Organization – unike behov

82Norse 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.

83- **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.

84- **Testformål:** Sikre at kombinasjonen av alle aktiverte moduler ikke gir konflikter i navigasjon, API-respons, eller admin-portal.

85- **Alle matrisefunksjoner:** Norse Test er eneste organisasjon med ✓ på absolutt alle behovspunkter i §4-matrisen.

86- **Ingen organisasjonsspesifikke begrensninger:** Terminologi, labels og config-flagg er satt til standardverdier for å unngå at org-spesifikke overrides skjuler feil i standardoppsett.

87- **Brukes ikke i produksjon:** Data generert av Norse Test-organisasjonen er testdata og skal ikke inngå i Bufdir-rapportering eller øvrig ekstern rapportering.

88## 4. Behovsoversikt – prioriteringsmatrise

89> **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.

90| Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Norse Test | Prioritet | Fase |

91|-|-|-|-|-|-|-|-|

92| Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |

93| Universell utforming / tilgjengelighet (WCAG 2.2 AA) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |

94| BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |

95| Bufdir-rapportering (eksport, admin) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |

96| Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |

97| TestFlight (iOS) + Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |

98| Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 |

99| Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | ✓ | NICE TO HAVE | 3 |

100| Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 |

101| Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | ✓ | SHOULD HAVE | 2 |

102| Tale-til-tekst | – | – | ✓ | ✓ | ✓ | SHOULD HAVE | 2 |

103| Kryptert oppdragshåndtering | – | – | ✓ | – | ✓ | MUST (Blindeforbundet) | 2 |

104| Formalisert rapportstruktur | ✓ | – | ✓ | – | ✓ | NICE (Blind. + Barnekreft) | 3 |

105| Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | ✓ | SHOULD (HLF + Barnekreft) | 3 |

106| Koordinering med ekstern portal | – | – | – | ✓ | ✓ | MUST (HLF) | 2 |

107| Dokumentvedlegg til aktiviteter | – | ✓ | – | – | ✓ | NICE TO HAVE | 2 |

108| Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |

109| Snakkekort | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 3 |

110| Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 |

111| Pårørende database | ✓ | – | – | – | ✓ | MUST (Barnekreft) | 1 |

112| Basic search (contact og notater) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST | 1 |

113| Notater | ✓ | ✓ | ✓ | ✓ | ✓ | NICE | 2 |

114| Verving / Referral (invite-link, rekruttering) | – | – | – | ✓ | ✓ | SHOULD (HLF) | 3 |

115### Product Landscape — Meander Platform

116Meander 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.

117**Product 1: Meander Mobile App** (Flutter)

118- Purpose: Day-to-day operational tool for peer mentors and coordinators

119- Users: Peer Mentors (Likepersoner), Coordinators (Organization Admins appear as Coordinators on mobile)

120- Core capabilities (always available):

121  - Activity registration (quick logging, wizards, bulk/proxy)

122  - Contact and peer mentor management

123  - Personal statistics and impact summaries

124  - Push notifications and assignment tracking

125- Optional capabilities (toggled per organization):

126  - Travel expense registration (`expense-reimbursement`)

127  - Speech-to-text input (config flag on `activity-registration`)

128  - Document attachments to activities

129  - Gamification — wrapped summaries, badges (`achievements-gamification`)

130  - Encrypted assignments (`encrypted-assignments`)

131  - Course registration & certification (`certification-training`)

132- Tech: Flutter, Riverpod (no codegen), Drift (offline), WCAG 2.2 AA

133**Product 2: Admin Web Portal** (Next.js)

134- Purpose: Organization management, reporting, and oversight

135- 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.

136- Core capabilities:

137  - User management (invite, deactivate, role assignment)

138  - Organization settings and terminology/labels configuration

139  - Bufdir report generation and one-click export

140  - Activity oversight, approval workflows, and corrections

141  - Reimbursement approval and expense oversight

142  - Coordinator and organization-level dashboards and KPIs

143  - Multi-organization hierarchy management

144  - Course and certification administration

145- Tech: Next.js on Vercel, server-side rendering, same auth system

146**Product 3: Authentication Module**

147- 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.

148- 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.

149- Core capabilities:

150  - Email/password sign-in for MVP; BankID and Vipps in Phase 2

151  - Short-lived access tokens plus rotating refresh tokens

152  - Session revocation (sign-out, forced expiry, admin-initiated)

153  - Per-tenant isolation of signing material

154  - A clean extension point for attaching product-specific claims (role, organization memberships) without the auth module knowing the product's schema

155- Boundaries:

156  - Owns only identity and session state. No product data, no authorization logic, no role semantics.

157  - Authorization (who can do what within a product, tenant scoping, audit of domain actions) is the consuming product's responsibility.

158  - Exposes a stable contract (sign-in, sign-out, refresh, identity lookup) so consumers do not depend on its internals.

159- 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.

160**Product 4: Product Sales Website** (simple static site)

161- Purpose: Public information site for prospective organizations — explains what Meander is, shows features, and collects demo requests.

162- Users: Prospective organizations, buyers, decision-makers

163- 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.

164- Core capabilities:

165  - Product landing page and feature overview

166  - Benefit / impact calculator (static calculation, no login)

167  - Demo booking form

168  - Privacy policy, Terms of Service, Data Processing Agreement, Cookie Policy

169- Tech: Static site (Next.js static export, Astro, or plain HTML/CSS). Public-facing, no auth, no backend dependency.

170### Module Toggles per Organization

171> **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.

172Not 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.

173**Design intent:**

174- **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.

175- **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.

176- **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.

177- **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.

178- **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:

179  - **Mobile App:** `authentication-access-control`, `home-navigation`, `accessibility`, `help-support`, `profile-management`.

180  - **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).

181  - The Sales Website is out of scope for module toggles entirely — it is a static information site with no module concept.

182- 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.

183- **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.

184- **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.

185- **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.

186This keeps the codebase single-tenant in shape while supporting multiple organizations with materially different needs, and leaves room for new tenants without a rewrite.

187### Core Roles & Access Boundaries

188Each organization has its own roles and users. Norse (the platform owner) manages global admins separately.

189**4 defined user roles:**

190- **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.

191- **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.

192- **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.

193- **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.

194### Core Operational Flow

1951. Peer mentor performs activity or event

1962. Activity is registered and tracked in Meander Mobile App

1973. Coordinator oversees follow-up, quality, and approval

1984. Org Admin gets overview in Admin Web Portal

1995. Structured data supports Bufdir reporting and analytics

200### Shared Backend

201Shared only by the **operational products** (Mobile App + Admin Web Portal). The Sales Website does not touch this backend.

202- **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`)

203- **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR)

204- **Database** (standard relational, managed) — no vendor-specific extensions, pure SQL with migrations

205- **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.

206### Mobile App Architecture

207**Auth & Access**

208- **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.

209- Email/password login

210- BankID / Vipps login (Phase 2)

211- Biometric session authentication (Face ID / fingerprint)

212- Role-based access control — Peer Mentor and Coordinator roles

213- No-access screen for Global Admin (redirected to admin portal)

214**Navigation**

215- Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications

216- Settings accessible from hamburger menu

217**Screens**

218- Role-specific home content (peer mentor vs coordinator variants)

219- Contacts list with role-specific views

220- Contact detail, edit, and peer mentor profile screens

221- Activity wizard (multi-step: contact → date → time → duration → summary)

222- Event wizard (multi-step: title → date → time → duration → location → summary)

223- Settings and preferences

224- Notification inbox

225**Core/Shared**

226- REST API client (`ApiHttpClient`) with JWT bearer, auto-refresh on 401, 15s timeout, and a typed `ApiException` hierarchy

227- Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver)

228- Optimistic mutations with automatic rollback on failure (contact edits and paginated list updates)

229- Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant

230- Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table

231- 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`)

232- 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.

233## 5. Anbefalt prioriteringsrekkefølge for teamet

234Fasene her speiler aksjonspunktene i §7. Fase 0 er mobiliseringsfasen (pre-utvikling) og er beskrevet i §7. Fase 1–4 nedenfor er utviklingsfasene.

235### Fase 1 – MVP (alle organisasjoner, vår)

236**Meander Mobile App (MVP scope):**

237- Aktivitetsregistrering med lavest mulig antall klikk og standardverdier

238- WCAG 2.2 AA compliance fra dag én – for alle organisasjoner, uten unntak

239- E-post/passord innlogging (BankID/Vipps i fase 2)

240- Enkel statistikkvisning per likeperson og per koordinator

241- Kontaktliste og likepersonsoversikt

242- 2 mobilrolle-profiler: Peer Mentor, Coordinator (Organization Admins logger på som Coordinator i app-konteksten)

243**Admin Web Portal (MVP scope):**

244- Brukeradministrasjon (invitere, deaktivere, rolletildeling)

245- Organisasjonsinnstillinger og terminologikonfigurasjon

246- Aktivitetsoversikt og grunnleggende statistikk

247- 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.

248**Shared Backend (MVP scope):**

249- REST API (Next.js på Vercel) med standard relasjonsdatabase

250- JWT-basert autentisering

251- Flerorganisasjonsstøtte (multi-tenancy)

252**Product Sales Website (MVP scope):**

253- Statisk landingsside med produktbeskrivelse og fordeler

254- Enkelt demo-booking-skjema (sender til e-post/webhook, ingen pålogging)

255- Privacy policy og vilkår

256### Fase 2 – Kjerneprodukt

257- Bufdir-rapportering og eksport med ett klikk (kun i Admin Web Portal; mobilen bidrar med selve aktivitetsregistreringen)

258- Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning)

259- Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk)

260- Pausefunksjon og bulkregistrering for koordinatorer

261- Tale-til-tekst i rapportskriving

262- BankID / Vipps innlogging

263- Dokumentvedlegg til aktiviteter (NHF)

264- Koordinering med HLFs eksterne portalprosjekt

265### Fase 3 – Vekst og engasjement

266- Gamification / «Ditt likepersonsår» (Wrapped, badges, Advantage Calculator)

267- Kursadministrasjon og sertifisering (HLF + Barnekreftforeningen)

268- Formalisert rapportstruktur (Blindeforbundet + Barnekreftforeningen)

269- Regnskapsintegrasjon (Xledger for Blindeforbundet, Dynamics accounting for HLF)

270- Mentorordning / Career Workshops (Blindeforbundet)

271- Geografisk kartvisning (Blindeforbundet)

272- Snakkekort / Talking Cards Toolbox

273- Digitalt likepersonsbevis

274- Verving / Referral (HLF)

275### Fase 4 – Spekulativt (forskningsideer, ikke bekreftet)

276Ingen bekreftede Fase 4-leveranser. Fordelskalkulator (Advantage Calculator) ligger inne i Achievements & Gamification-området og følger derfor Fase 3.

277- Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov

278- Dokumentsignering innenfor Kryptert oppdragshåndtering

279- Spill og interaktive elementer

280- Stikk motsatt av likepersonslogg

281- Ny validering av value proposition for neste tenant-bølge

282## 6. Fellesåpne punkter

283- Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner.

284- Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering.

285- Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon.

286- 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.

287- Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell.

288## 7. Neste aksjonspunkter

289Fasene her følger samme nummerering som §5. Fase 0 er mobiliseringsfase (pre-utvikling). Fase 1–4 er utviklingsfaser.

290### Fase 0 – Mobilisering (frem til 13. mars)

291- Strategisk: Playing to win → Value prop (Alle)

292- Oppdatere pengecase (Daniel & Lasse)

293  - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler.

294- Kontakte Bufdir (Daniel)

295- Panorama

296- Få opp nettside (Aleksander)

297- Oversikt over hva vi har allerede utviklet (Marius og Aleksander)

298- Plan for pilotering/testing (Marius, Aleksander og Gellert)

299  - Featureoversikt

300  - Raskt ut og iterere basert på læring

301- Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert)

302### Fase 1 – MLP / MVP

303- Scope to be decided

304- Hva har vi allerede

305- Hva må på plass

306- Enkel admin

307- Mobil: aktivitetsregistrering, WCAG, enkel statistikk

308- Admin: brukeradministrasjon, organisasjonsinnstillinger, aktivitetsoversikt

309### Fase 2 – Kjerneprodukt

310- Bufdir-rapportering (eksport i admin)

311- Reiserefusjon

312- Pause

313- Bulkregistrering

314- Kryptert oppdragshåndtering (Blindeforbundet)

315- BankID / Vipps

316- Tale-til-tekst

317### Fase 3 – Vekst og engasjement

318- Gamification

319- Wrapped

320- Kursadministrasjon / sertifisering

321- Snakkekort / toolbox

322- Lenker til kurs

323- Digitalt likepersonsbevis

324- Validere value prop

325### Fase 4 – Spekulativt

326Ingen bekreftede Fase 4-leveranser. Fordelskalkulator følger Fase 3 via Achievements & Gamification-området.

327- Signering (videreutvikling av Kryptert oppdragshåndtering)

328- Spill

329- Stikk motsatt av likepersonlogg

330- Validere value prop på ny

331- Pårørende-database-utvidelser utover Barnekreftforeningens MVP-behov

332**Note:** Pårørende-database er Fase 1 MUST for Barnekreftforeningen (se §4 matrisen).

333---

334## 8. Vocabulary — Canonical Area & Feature Structure

335> **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.

336>

337> **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.

338>

339> **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.

340>

341> **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.

342>

343> **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.

344### Mobile App — Areas

345| Area ID | Area Name | Features |

346|-|-|-|

347| authentication-access-control | Authentication & Access Control | Email & Password Login, BankID Authentication, Vipps Authentication, Biometric Login (Face ID/Fingerprint), Passkeys (WebAuthn), Role-Based Access Control |

348| profile-management | Profile Management | Profile Data & Settings, Profile Switching |

349| activity-registration | Activity Registration | Simple Activity Logging, Activity Registration Wizard, Calendar Sync, Speech-to-Text Input, Document Attachments, Formalized Home-Visit Report |

350| proxy-bulk-registration | Proxy & Bulk Registration | Coordinator Proxy Reporting, Bulk Registration |

351| event-management | Event Management | Event Creation, Event Listing, Event Sign-up |

352| expense-reimbursement | Expense & Reimbursement | Travel Expense Registration, Receipt Photo Upload, Expense Types & Requirements, Confidentiality Declarations |

353| contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin |

354| notes | Notes | Notes List, Note Editor |

355| statistics | Statistics | Personal Activity Statistics, Coordinator Team Reports |

356| encrypted-assignments | Encrypted Data Assignments | Encrypted Assignment Dispatch, Assignment Threshold Tracking, Progressive Digital Consent |

357| relatives-database | Relatives Database | Relative Contact Registration, Relative Case Linking, Relative Role Tagging |

358| peer-mentor-status | Peer Mentor Status | Pause Function, Resume Function, Certification Expiry Auto-Pause |

359| geographic-map-view | Geographic Map View | Peer Mentor Map, Assignment Matching by Geography |

360| mentor-program | Mentor Program | Career Workshops, Workshop Notes, Workshop Participant Lists, Workshop To-Do Lists |

361| notifications | Notifications | Push Notifications, Email/SMS Notifications, Notification Scenarios, Notification Settings |

362| referral-program | Referral Program | Invite Link & QR Sharing, Recruitment Tracking |

363| certification-training | Certification & Training | Course Registration, Digital Peer Mentor Certificate, Certificate Renewal Reminder |

364| achievements-gamification | Achievements & Gamification | Annual Summary (Wrapped), Achievement Badges, Advantage Calculator |

365| conversation-tools | Conversation Tools | Talking Cards Toolbox |

366| accessibility | Accessibility | WCAG 2.2 AA Compliance, Sensitive Field Readout Warning |

367| home-navigation | Home & Navigation | Role-Specific Home Dashboard, App Settings & Preferences, External Resource Links |

368| help-support | Help & Support | Contact Us, Privacy Policy, Accessibility Statement, FAQ |

369| offline-sync | Offline & Sync | Offline Data Support, Background Sync |

370### Admin Portal — Areas

371| Area ID | Area Name | Features |

372|-|-|-|

373| admin-dashboard | Admin Dashboard | Dashboard KPIs, Activity Feed |

374| admin-user-management | User Management | User CRUD, Role Assignment, Bulk Actions |

375| admin-activity-oversight | Activity Oversight | Activity Review & Approval, Activity Flagging, Duplicate Activity Detection |

376| admin-expense-approval | Expense Approval | Expense Approval Queue, Auto-Approval Rules, Reimbursement Overview |

377| admin-reporting | Reporting & Export | Team Reports, Bufdir Report Generation, Bufdir Export, Custom Reports |

378| admin-organization | Organization Management | Organization Settings, Custom Terminology, Feature Toggles, Multi-Organization Hierarchy, Member Associations, External Portal Integration (HLF config flag) |

379| admin-accounting | Accounting Integration | Accounting API, Accounting Export |

380| admin-security | Security & Audit | Security Dashboard, Audit Log, Session Management |

381### Sales Website — Areas

382| Area ID | Area Name | Features |

383|-|-|-|

384| sales-product | Product Showcase | Product Landing Page, Feature Overview |

385| sales-calculator | Benefit Calculator | Impact Calculator, Cost Comparison |

386| sales-demo | Demo Booking | Booking Form, Booking Confirmation |

387| sales-legal | Legal Documents | Privacy Policy, Terms of Service, DPA, Cookie Policy |

388### Terminology

389| Term | Definition | Norwegian |

390|-|-|-|

391| Peer Mentor | Volunteer who provides support to contacts | Likeperson |

392| Coordinator | Staff member who manages peer mentors | Koordinator |

393| Organization Admin | Administrator of a single organization | Organisasjonsadministrator |

394| Global Admin | Administrator across all organizations | Global administrator |

395| Contact | Person receiving support from a peer mentor | Kontakt (overrideable per org via the Organization Labels system, e.g. `Familie`, `Bruker`) |

396| Activity | A logged interaction (home visit, phone call, meeting, etc.) | Aktivitet |

397| Assignment | Encrypted sensitive data dispatch to a peer mentor | Oppdrag |

398| Reimbursement | Expense claim for travel or other costs | Refusjon / Utlegg |

399| Bufdir | Norwegian government agency funding the program | Bufdir |

400| Area | High-level functional grouping in the platform | Omrade |

401| Feature | Specific capability within an area | Funksjon |

# Tverrgående workshopsammendrag ## Behovskartlegging – Likepersonsapp **Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen, Norse Test Organization** **Version 8.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 |