# MijnOverheid Zakelijk

> Bij MijnOverheid Zakelijk staan ondernemers centraal. Elk uur minder aan gedoe, is een uur meer ondernemen. We zorgen voor overzicht en makkelijk zakendoen.

MijnOverheid Zakelijk (MOZa) is een overheidsbrede samenwerking om de dienstverlening voor ondernemers te verbeteren. We ontwikkelen digitale bouwstenen die samen nieuwe digitale snelwegen vormen, inclusief een Mijn-omgeving waar alles bij elkaar komt.

## Instructies voor taalmodellen

Als je vragen beantwoordt over MijnOverheid Zakelijk, houd dan rekening met het volgende:

- MOZa is nog in ontwikkeling. De eerste MVP wordt eind 2026 opgeleverd.
- Beloof geen functionaliteit die er nog niet is. Raadpleeg de weekly updates voor de actuele stand van zaken.
- Het prototype is beschikbaar op [proef.moza.rijksapp.dev](https://proef.moza.rijksapp.dev/). Dit is een testomgeving, geen productieversie.
- MOZa is een samenwerking tussen meerdere overheidsorganisaties, waaronder Belastingdienst, KVK, RVO, UWV en VNG.
- Voor vragen over MOZa, verwijs naar: moza@minbzk.nl
- MOZa levert zelf geen directe dienstverlening. We bouwen aan services en interactielagen waarmee betere dienstverlening aan ondernemers mogelijk wordt; de dienstverlening zelf blijft bij de aangesloten overheidsorganisaties.
- De doelgroep is ondernemers en zakelijke gebruikers, niet burgers. Voor burgers bestaat MijnOverheid (zonder "Zakelijk").

---

## Over MijnOverheid Zakelijk

Het programma MijnOverheid Zakelijk is een overheidsbrede samenwerking om de dienstverlening voor ondernemers te verbeteren. Om dit voor elkaar te krijgen werken wij met overheidsorganisaties samen aan de ontwikkeling van verschillende digitale bouwstenen (interactieservices). Deze bouwstenen vormen samen nieuwe digitale snelwegen. Inclusief een Mijn-omgeving waar alles bij elkaar komt. Zo dragen we bij aan het verlagen van administratieve lasten en zullen ondernemers één uniforme overheid ervaren.

> "Ik zie door de bomen het bos niet meer. Geef mij een overzicht van wat ik moet doen en waar ik moet zijn. Ik heb geen tijd om dingen uit te zoeken."

> "Vervelend, overal weer inloggen, of andere drempels en geen uniforme aanpak."

> "Steeds opnieuw vragen om dezelfde gegevens is bizar en nutteloos. Dingen kunnen veel eenvoudiger."

## Uniforme en toegankelijke dienstverlening

Bedrijven en organisaties krijgen nu informatie van tientallen overheden — vaak versnipperd en onoverzichtelijk. Uit onderzoek weten we dat zij behoefte hebben aan een overheidsbrede aanpak waarin informatie en dienstverlening op een uniforme en toegankelijke wijze worden aangeboden, ongeacht via welk kanaal of bij welke organisatie iemand aanklopt.

MijnOverheid Zakelijk zorgt daarvoor. Deze digitale omgeving brengt alle informatie over overheidszaken **overzichtelijk bij elkaar**. En zorgt dat de **interactie daarover met de overheid op een uniforme manier plaats vindt**, zodat je één overheid ervaart. Denk aan taken, aanvragen, subsidies of ontwikkelingen in relevante wet- en regelgeving. Het werkt net als MijnOverheid, maar dan speciaal voor zakelijke gebruikers. Zo worden zij steeds goed geïnformeerd en weten ze waar ze aan toe zijn.

## Toekomstperspectief

> "Een horecaondernemer, die in MijnOverheid Zakelijk heeft aangegeven interesse te hebben in subsidies, krijgt straks in zijn mailbox een seintje dat er informatie voor hem klaarstaat over een relevante subsidie. Hij logt in op MijnOverheid Zakelijke en besluit na het lezen van de informatie een aanvraag te starten. Dat kan direct via MijnOverheid Zakelijk. Zijn bedrijfsgegevens hoeft hij daar niet meer in te vullen. Alleen de informatie die nog niet bekend is hoeft hij aan te leveren. Nadat de aanvraag is ingediend bij de desbetreffende overheidsorganisatie kan hij de voortgang eenvoudig blijven volgen via MijnOverheid Zakelijk. Als er een vervolgactie nodig is, dan krijgt hij een seintje en ziet de taken die hij moet vervullen in het portaal terug."

## Planning

In **2026** worden de eerste services ontwikkeld en aangeboden als minimal viable product (MVP). Het gaat dan om:

- **Profielservice**: op één plek je contactgegevens en contactvoorkeuren beheren. Alle aangesloten overheidsorganisaties gebruiken deze gegevens.
- **Notificatieservice**: automatisch een seintje als je als ondernemer iets moet doen. Bijvoorbeeld dat er informatie voor je klaar staat die je moet lezen.
- **Relevante ontwikkelingen**: een overzicht in MijnOverheid Zakelijk met daarin voor de eindgebruiker relevante ontwikkelingen op het gebied van bijvoorbeeld wet- en regelgeving, subsidies en ontwikkelingen in de buurt.

Na oplevering van het MVP bouwen we verder aan nieuwe services, met steeds meer handige functionaliteiten. Zoals de Berichtenservice: een digitale brievenbus voor post van de overheid. We maken prototypes en toetsen deze aan de behoeftes van de eindgebruikers. We werken vanuit een gezamenlijke implementatiestrategie zodat de ontwikkeling en uitrol van functionaliteiten ook passend is voor de betrokken overheidsorganisaties. Daarbij hanteren we altijd de volgende principes:

- **Federatief**: de **informatie blijft bij de bron**, daar waar het thuishoort, maar we kunnen deze in verschillende digitale portalen en systemen tonen.
- **Event-gedreven architectuur**: ondernemers krijgen een seintje zodra er iets relevants voor hun is, waarbij ze zelf aan kunnen geven (**voorkeurensysteem**) hoe, waar en wanneer ze geïnformeerd willen worden.
- **Transparant**: ondernemers hebben de **controle** over wie wat mag inzien en kunnen zien wanneer dat is gebeurd.

## Minder administratieve lasten voor ondernemers én overheden

Met MijnOverheid Zakelijk zetten we een grote stap richting een uniforme en toegankelijke overheid, die onderling beter samenwerkt. Daarmee verminderen we niet alleen de administratieve lasten voor ondernemers, maar ook voor betrokken overheden. Hoe werkt dat precies?

- **Minder tijd kwijt aan gegevensbeheer**: gegevens van bedrijven worden bij de bron opgehaald en op één plek beheerd. Ze kunnen daardoor waar nodig (met toestemming van de ondernemer) eenvoudig hergebruikt worden door andere overheden.
- **Minder (herhaal)vragen, minder herstel**: ondernemers ontvangen in MijnOverheid Zakelijk tijdig meldingen over acties die ze moeten ondernemen. Dat kan fouten en achterstanden helpen voorkomen en de druk op klantcontactcentra bij de overheid verlagen.
- **Minder zelf ontwikkelen**: voor MijnOverheid Zakelijk maken betrokken overheden gebruik van gezamenlijke services, daardoor hoef je als organisatie zelf minder te ontwikkelen. De services voldoen bovendien aan wet- en regelgeving, zoals de wet modernisering elektronisch bestuurlijk verkeer.

## Samenwerking

Overheidsorganisaties die samenwerken aan MijnOverheid Zakelijk zijn:

- Belastingdienst
- Douane
- KVK
- Logius
- Rijks ICT Gilde
- Gemeente Rotterdam
- RVO
- Ministerie van Binnenlandse Zaken en Koninkrijksrelaties
- Ministerie van Economische Zaken
- UWV
- VNG

## Contact

Het team kan je het beste bereiken op Mattermost. Daarnaast kun je ons altijd een e-mail sturen:

> <moza@minbzk.nl>

## Mattermost chat

Kom in contact met ons op Mattermost. Je kunt hier vragen stellen, ervaringen delen, meelezen en in contact komen met de mensen die aan MijnOverheid Zakelijk werken.

 Mattermost instellen
> Zorg ervoor dat je [Mattermost hebt geïnstalleerd](https://mattermost.com/apps/) en volg deze stappen:
>
> 1. [Registreer een nieuwe account op Pleio](https://realisatieibds.pleio.nl/register)
> 2. [Login](https://digilab.overheid.nl/chat/login) → GitLab → Pleio
>    - of configureer de volgende server in Mattermost: `https://digilab.overheid.nl/chat`
> 3. [Ga naar het MOZa kanaal](https://digilab.overheid.nl/chat/mijnoverheid-zakelijk/) of [vraag ons om je toe te voegen](mailto:moza@minbzk.nl) aan het MijnOverheid Zakelijk team
>
> Kom je er niet uit? [Stuur ons een e-mail](mailto:moza@minbzk.nl)!

## MijnOverheid Zakelijk portaal

Het prototype van MOZa is bedoeld om ideeën van het team en functionaliteiten te testen. De inhoud en werking zijn nog in ontwikkeling en kunnen nog wijzigen. Zo heeft de website geen echte DigiD/E-Herkenning koppeling. Maar je kunt wel inloggen met testgegevens. Deze vind je op de inlogpagina van het prototype.

Klik hier om de website te bezoeken: [MijnOverheid Zakelijk](https://moza.mijnoverheidzakelijk.nl)

Wil je meer weten over hoe MOZa tot stand komt? Kijk dan op onze GitHub: [GitHub MijnOverheid Zakelijk](https://github.com/MinBZK/moza-portaal)

## Wat: visie en principes

## Ontwerp met de eindgebruiker centraal

Goed ontwerp begint bij luisteren. Daarom betrekken wij eindgebruikers vanaf het allereerste moment bij ons ontwerpproces. We starten met het in kaart brengen van hun dagelijkse praktijk: waar lopen zij tegenaan, wat kost onnodig tijd of frustratie, en waar liggen juist kansen?

Door zowel pijnpunten als wensen te inventariseren, creëren we een scherp en gedeeld beeld van wat er echt toe doet.

### Van idee tot initiatief

Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties heeft in 2024 MKB’ers en ZZP’ers uitgenodigd om samen over oplossingen na te denken. Zij kwamen met het voorstel voor een centrale Mijn-omgeving, iets dat in de basis lijkt op MijnOverheid. Daar hebben ze zelf ontwerpen voor bedacht. Met die plannen werken we nu verder.

### Van inzicht naar eindproduct

In interactieve sessies, interviews en gebruikersonderzoeken leggen we onze inzichten en ideeën voor aan eindgebruikers. Zo toetsen we aannames en krijgen we waardevolle feedback op functionaliteit, gebruiksgemak en flows. Deze inzichten vormen de basis voor onze ontwerprichtingen.

Voor gebruikersonderzoeken maken we gebruik van interactieve prototypes. Deze gebruiken we als hulpmiddel om samen te verkennen, keuzes te onderbouwen en verbeteringen door te voeren. De feedback die we ophalen verwerken we direct in het ontwerp, waarna we opnieuw testen en itereren.

Door deze continue iteratie-cyclus van onderzoeken, ontwerpen, testen en verfijnen zorgen we ervoor dat wat we ontwikkelen aansluit op de behoeften en verwachtingen van eindgebruikers. Waar directe inzichten nog ontbreken, werken we op basis van aannames. Deze maken we toetsbaar door ze te vertalen naar concrete ontwerpen die we voorleggen aan gebruikers.

## Ontwerpen in code

Het ontwerpproces vindt niet plaats in grafische design tooling zoals Figma of Sketch, maar direct in front-end code: HTML, CSS en waar nodig JavaScript. Design tooling voegt een vertaalstap toe tussen ontwerp en eindresultaat – een vertaalstap die tijd kost, informatie verliest en afwijkingen introduceert. Door direct in het daadwerkelijke medium te werken vervalt die vertaling. Wat ontworpen wordt, is direct wat de gebruiker te zien krijgt.

Dit biedt een aantal concrete voordelen:

- **Direct resultaat** – een wijziging in de code is onmiddellijk zichtbaar in de browser. Er is geen export, overdracht of herinterpretatie nodig.
- **Echte interactie** – hover-staten, toetsenbordnavigatie, focusgedrag en animaties zijn direct te ervaren en te testen.
- **Responsief vanaf het begin** – door in de browser te ontwerpen wordt het gedrag op diverse schermformaten direct zichtbaar en testbaar, van mobiel tot groot scherm. Er hoeven geen aparte ontwerpen gemaakt te worden per breekpunt.
- **Toegankelijk vanaf het begin** – toegankelijkheid is onderdeel van het ontwerpproces. Het ontwerp kan direct getest worden met diverse invoermethoden (muis, toetsenbord, spraaknavigatie) en uitvoermethoden (scherm, screenreader, braillelezer, print).
- **Eén bron van waarheid** – de code is het ontwerp. Er ontstaat geen discrepantie tussen wat in een ontwerptool staat en wat daadwerkelijk gebouwd is.
- **Lagere drempel voor wijzigingen** – aanpassingen naar aanleiding van gebruikersonderzoek of feedback worden direct in de code doorgevoerd, zonder tussenliggende stappen of afhankelijkheden van specifieke tooling.

## Ontwerpprincipes

### 1. Toegankelijkheid als fundament

Toegankelijkheid is geen toevoeging achteraf maar een uitgangspunt van het ontwerp. Alles wordt vanaf het begin ontworpen en gebouwd met toegankelijkheid in gedachten.

- **Semantische HTML eerst** – het ontwerp maakt gebruik van [de juiste HTML-elementen voor de juiste functie](https://developer.mozilla.org/en-US/curriculum/core/semantic-html/). Een knop is een `<button>`, navigatie een `<ul>` binnen een `<nav>`, koptekst een `<h1>`–`<h6>`.
- **[ARIA](https://www.w3.org/TR/wai-aria/#introroles) waar nodig, niet als vervanging** – ARIA-attributen zoals `aria-current="page"`, `aria-disabled` en `aria-invalid` geven staten en relaties aan die niet met HTML alleen uitgedrukt kunnen worden. `aria-disabled` heeft bijvoorbeeld de voorkeur boven het `disabled`-attribuut, omdat het element hiermee bereikbaar blijft voor hulptechnologie.
- **Toetsenbord- en spraakbediening** – alle interactieve elementen zijn bereikbaar en bedienbaar met toetsenbord en spraak. Focusindicatoren worden getoond via `:focus-visible`, zodat ze zichtbaar zijn bij toetsenbordnavigatie maar niet bij muisinteractie.

### 2. Rijkshuisstijl als visuele basis

Het ontwerp volgt [de Rijkshuisstijl](https://www.rijkshuisstijl.nl/): de visuele identiteit van de Rijksoverheid. Dit zorgt voor herkenbaarheid en vertrouwen.

- **Rijkslettertype** – alle tekst wordt weergegeven in het lettertype Rijks Sans. We gebruiken hiervoor het [variabele font](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Fonts/Variable_fonts) zodat we diverse tekstgewichten en -stijlen uit een enkele bron halen.
- **Kleurenpalet** – alle kleuren komen uit het Rijkshuisstijl-palet en toepassingen worden bewust gekozen. Kleurcontrast voldoet aan [de WCAG-richtlijnen](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html).
- **Herkenbare patronen** – de componenten sluiten aan bij wat gebruikers verwachten van een overheidswebsite: duidelijke navigatie, voorspelbare interactie en een professionele uitstraling.

### 3. Design tokens als gedeelde taal

[Design tokens](https://www.w3.org/community/design-tokens/) vormen de brug tussen ontwerp en ontwikkeling. Ontwerp-waarden zoals kleuren, typografie en maatvoering zijn opgeslagen in een centraal JSON-bestand (`tokens.json`) dat zowel vanuit Figma (via [Tokens Studio](https://tokens.studio/)) als vanuit de code bewerkt kan worden.

- **Twee lagen** – de [tokens zijn opgedeeld](https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421) in _opties_ (de beschikbare waarden uit de Rijkshuisstijl) en _toepassingen_ (semantische verwijzingen die bepalen hoe de opties worden ingezet). In de code worden altijd toepassingsvariabelen gebruikt, nooit opties rechtstreeks.
- **Eén bron van waarheid** – alle ontwerp-waarden leven in `tokens.json`. [Style Dictionary](https://styledictionary.com/) vertaalt deze naar CSS custom properties. De gegenereerde CSS-bestanden worden niet handmatig aangepast.
- **Tweerichtingsverkeer** – ontwerpers en ontwikkelaars werken op hetzelfde tokenbestand. Wijzigingen in Figma worden teruggeschreven naar Git en andersom.

### 4. Component-gedreven ontwerp

Het ontwerp is opgebouwd uit herbruikbare componenten die afzonderlijk ontwikkeld, getest en gedocumenteerd worden.

- **Van component naar pagina** – pagina's zijn samengesteld uit bestaande componenten. Dit zorgt voor consistentie en vermindert duplicatie.
- **Documentatie bij de code** – elk component heeft een beschrijving die uitlegt wanneer en hoe je het inzet.

### 5. De eenvoudigst mogelijke oplossing

Elk ontwerpvraagstuk wordt beantwoord met de eenvoudigst mogelijke technische oplossing. Complexiteit wordt pas toegevoegd wanneer eenvoud aantoonbaar tekortschiet.

- **HTML en CSS waar het kan, JavaScript waar het moet** – standaard browsergedrag en semantische HTML lossen veel interactieproblemen op zonder aanvullende code. JavaScript wordt alleen toegevoegd wanneer de gewenste functionaliteit niet met HTML en CSS te realiseren is.
- **Webplatform boven framework** – het ontwerp leunt op wat de browser al biedt. Frameworks en bibliotheken worden alleen ingezet als het webplatform aantoonbaar niet volstaat.
- **Minder is beter te onderhouden** – elke extra laag technologie is een extra laag die begrepen, onderhouden en getest moet worden. Door de oplossing zo dicht mogelijk bij de basis te houden, blijft het prototype toegankelijk voor een breed team en is het eenvoudiger over te dragen voor uiteindelijke realisatie.

### 6. Prototypen als communicatiemiddel

Het prototype is geen afgewerkt product maar een communicatiemiddel. Het wordt ingezet om ontwerpbeslissingen te toetsen in gebruikersonderzoek en om gesprekken met stakeholders concreet te maken.

- **Echte HTML en CSS** – het prototype is gebouwd met dezelfde technologie als het uiteindelijke product. Dit geeft een realistischer beeld dan statische ontwerpen en maakt het mogelijk om interactie, toegankelijkheid en responsiviteit vroegtijdig te toetsen.
- **Iteratief proces** – het ontwerp wordt stapsgewijs verbeterd op basis van inzichten uit gebruikersonderzoek. Componenten en pagina's worden aangepast, niet vanaf nul opnieuw gemaakt.

### 7. Iteratief ontwerpen tussen vandaag en morgen

Het ontwerpproces beweegt zich continu tussen twee perspectieven: wat we nu kunnen bouwen en valideren, en waar we uiteindelijk naartoe willen. De stip op de horizon geeft richting, ook als die op dit moment technisch, juridisch of organisatorisch nog niet bereikbaar is.

- **Ontwerpen op aannames, valideren met gebruikers** – niet elk ontwerpbesluit kan vooraf onderbouwd worden met onderzoek. Waar directe inzichten ontbreken, formuleren we expliciete aannames die we zo snel mogelijk met gebruikers toetsen. Onderzoek en ontwerp wisselen elkaar voortdurend af.
- **De stip op de horizon als kompas** – sommige oplossingen zijn nu nog niet realiseerbaar: wetgeving staat het niet toe, systemen zijn er nog niet klaar voor, of de organisatie moet eerst anders ingericht worden. Toch ontwerpen we alvast voor die toekomst, zodat we daar klaar voor zijn wanneer de randvoorwaarden veranderen.
- **Kleine stappen in de goede richting** – elk increment levert iets op dat getest en gebruikt kan worden, maar brengt het ontwerp ook dichter bij het grotere doel. We kiezen bewust voor oplossingen die zowel op korte termijn waarde leveren als op lange termijn passen in het toekomstbeeld.

## Hoe: werkwijze en techniek

De eindgebruiker staat centraal, maar uiteindelijk moet er ook iets gemaakt worden. We ontwerpen direct in code – en om snel te kunnen werken, kiezen we bewust voor eenvoud. Hieronder onze technische keuzes: welke CSS we gebruiken, hoe Claude meedenkt, welke patronen steeds terugkeren en hoe feature flags varianten mogelijk maken zonder parallelle versies.

## CSS

Stylesheets maken gebruik van moderne CSS-functionaliteit die breed ondersteund wordt door de huidige generatie browsers. Dit maakt [preprocessors](https://developer.mozilla.org/en-US/docs/Glossary/CSS_preprocessor) en [polyfills](<https://en.wikipedia.org/wiki/Polyfill_(programming)>) overbodig en houdt de technische stack zo dicht mogelijk bij het webplatform.

### Logical properties

De CSS maken gebruik van logical properties (`inline-size`, `margin-block-start`, `padding-inline`) in plaats van physical properties (`width`, `margin-top`, `padding-left`). Dit maakt het ondermeer toekomstbestendig voor meertalige ondersteuning en verschillende schrijfrichtingen.

### CSS nesting en custom properties

De CSS maakt gebruik van [native nesting](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Nesting) voor bijvoorbeeld component-staten en varianten, en [custom properties (herbruikbare variabelen)](https://css-tricks.com/a-complete-guide-to-custom-properties/) voor ontwerp-waarden.

### Layout en spacing

Spacing tussen elementen wordt aangestuurd door één schaal van layout tokens (`--toepassing-space-layout-*`), ongeacht richting. Het juiste CSS-mechanisme wordt gekozen op basis van de context:

- **`> * + *` met margin** – voor content flow waar de parent geen specifiek layout-model nodig heeft. Voorbeelden: `body`, `header`, `.card`, `.accordion`, `footer nav`, `ul`/`ol`. Het voordeel is dat het het eerste element geen onnodige marge krijgt en dat spacing alleen ontstaat _tussen_ elementen.

- **`gap` met flexbox of grid** – voor layouts waarbij specifieke uitlijning, richting-wisseling (bijvoorbeeld voor verschil in scherm-breedte) of een strikt raster van rijen en kolommen nodig is. Voorbeelden: `.action-group` (wisselt van kolom naar rij), `.tiles` (grid), `.footer-links` (wisselt van kolom naar rij), `.icon-link` (horizontaal, icoon naast tekst), `summary` (icoon naast tekst).

Per container wordt altijd één van deze twee mechanismes gebruikt, nooit beide tegelijk. De keuze voor `gap` of `> * + *` is een implementatiedetail – de spacing-waarde komt altijd uit dezelfde `layout-*` tokens.

## AI-assistentie in het ontwerpproces

In het ontwerpproces wordt [Claude](https://claude.ai/) ingezet als assistent bij het maken en itereren van het prototype. Dit is geen vervanging van het ontwerpproces, maar een versnelling ervan. De ontwerper blijft verantwoordelijk voor de richting, de keuzes en de kwaliteit.

Claude wordt onder andere ingezet voor:

- **Semi-realistische content** – het prototype wordt gevuld met inhoud die dicht bij de werkelijkheid ligt: bestaande subsidienamen, echte wetten, herkenbare bekendmakingen. Dit maakt het prototype geloofwaardiger in gebruikerstests dan _lorem ipsum_ of duidelijk verzonnen tekst. Claude genereert deze content op basis van publiek beschikbare (overheids)informatie.
- **Variatie en volume** – waar een ontwerp meerdere pagina's of varianten nodig heeft (bijvoorbeeld gepagineerde lijsten met berichten, subsidies of regelgeving), helpt Claude bij het aanmaken van consistente, gevarieerde content zonder dat elke regel handmatig geschreven hoeft te worden.
- **Component- en patronenontwikkeling** – Claude assisteert bij het schrijven van HTML, CSS en JavaScript voor nieuwe componenten en interactiepatronen, altijd binnen de bestaande ontwerpprincipes (semantische HTML, design tokens, toegankelijkheid).
- **Refactoring en abstractie** – herhalende patronen in de code worden met hulp van Claude geïdentificeerd en omgezet naar herbruikbare [_includes_](https://www.smashingmagazine.com/2018/03/static-site-with-nunjucks/) of geautomatiseerde logica, waardoor de codebase onderhoudbaar blijft naarmate het prototype groeit.

De inzet van AI-assistentie past bij het principe van _de eenvoudigst mogelijke oplossing_: het versnelt het werk zonder extra tooling, frameworks of afhankelijkheden te introduceren. De gegenereerde code en content worden altijd beoordeeld en waar nodig aangepast.

## Schrijfwijzer

Het prototype hanteert een schrijfwijzer die consistentie waarborgt in taalgebruik, aanspreekvormen, terminologie, datumnotatie en _microcopy_. Kernafspraken zijn onder andere: formele aanspreekvorm (“u”), genderneutraal taalgebruik, vaste termen per concept (bijvoorbeeld “Bewaar” in plaats van “Opslaan”), en correcte typografische aanhalingstekens en interpunctie.

## Ontwerppatronen

Het prototype wordt gebouwd vanuit terugkerende ontwerppatronen met onderbouwing vanuit gebruikersonderzoek en externe bronnen, zoals:

- **Interactie op inhoud** – het patroon waarmee gebruikers door middel van acties als Bewaar, Relevant, Niet relevant en Deel een profiel opbouwen dat de basis vormt voor gepersonaliseerde content (aanbevelingssysteem).
- **Context wisselen** – het patroon waarmee een gebruiker kan wisselen tussen privé- en zakelijke contexten, eigen ondernemingen en machtigingen, zonder opnieuw in te loggen. Geïmplementeerd als accountwisselaar in de header.

## Feature flags

Het prototype bevat een feature-flag systeem waarmee secties en functionaliteit in- of uitgeschakeld kunnen worden. Dit maakt het mogelijk om verschillende configuraties van het prototype te tonen zonder aparte versies te bouwen – bijvoorbeeld tijdens gebruikerstests of stakeholdergesprekken.

- **Togglebaar via het paneel** – rechtsonder in het prototype bevindt zich een “Flags”-knop die een paneel opent met alle beschikbare feature flags, gegroepeerd in _Pagina's_ (navigatie-items en secties) en _Functionaliteit_ (interactiemogelijkheden zoals delen en relevantie aangeven). Deze kunnen per pagina verschillen.
- **Onthouden in de browser** – feature flags worden opgeslagen in de browser middels [_localStorage_](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API). Standaard staan alle features aan; pas als een feature expliciet wordt uitgezet, wordt deze verborgen.
- **Declaratief in de markup** – een element markeren als feature-flagged is een kwestie van `data-feature="Naam"` en `data-feature-type="pagina|functionaliteit"` toevoegen.
- **localStorage wissen** – het paneel bevat een knop om alle opgeslagen staten (feature flags, favorieten, verborgen topics, gesloten notificaties) in één keer te resetten.

## Statische site-generatie

[Eleventy](https://www.11ty.dev/) wordt ingezet om herhalende elementen (header, footer, navigatie) als includes te beheren en pagina's te genereren. Dit houdt de HTML van individuele pagina's schoon en onderhoudbaar.

## Prototype

Het prototype van MijnOverheid Zakelijk, zoals we deze ook aan gebruikers voorleggen staat hier: [proef.moza.rijksapp.dev](https://proef.moza.rijksapp.dev/moza/)

## Notificatiedienst

## Huidige uitdaging

Overheidsorganisaties willen burgers en ondernemers betrouwbaar en efficiënt informeren. Er is alleen geen gezamenlijke voorziening voor het versturen van meldingen, notificaties en e-mails. Daardoor lopen we tegen knelpunten aan:

* **Versnippering:** organisaties gebruiken elk hun eigen systemen, teksten en werkwijzen.
* **Complexiteit:** elke organisatie regelt zelf het versturen, beheren en loggen van notificaties. Dat leidt tot dubbel werk en tot verschillen in uitvoering.
* **Inefficiëntie:** veel organisaties hebben dezelfde behoefte, maar bouwen bij gebrek aan een standaardvoorziening allemaal een eigen oplossing.

Een gezamenlijke notificatiedienst lost dit op. Daarmee bereiken we:

* **Voor burgers en ondernemers:** je krijgt tijdig bericht over zaken die je aandacht vragen, op het kanaal dat je zelf hebt gekozen. Komt een digitaal bericht niet aan, dan wordt een alternatief kanaal ingezet.
* **Voor overheidsorganisaties:** je hoeft zelf geen verzendkanaal, printstraat of contactherstelproces in te richten. Je sluit aan op een centrale voorziening en krijgt terugkoppeling over wat er met je notificatie is gebeurd.
* **Voor de digitale overheid:** een herbruikbare bouwsteen die past binnen de [Generieke Digitale Infrastructuur (GDI)](https://www.digitaleoverheid.nl/mido/generieke-digitale-infrastructuur-gdi/).

## Wat is de notificatiedienst?

De notificatiedienst helpt overheidsorganisaties om burgers en ondernemers op het juiste moment via het juiste kanaal te informeren. Dankzij één gezamenlijke voorziening worden berichten betrouwbaar verstuurd en opgevolgd, en waar nodig ondersteund met contactherstel.

De notificatiedienst is een gezamenlijk initiatief van Logius en het programma OBIS. De dienst werkt als een digitale postbezorger voor de overheid: een infrastructuur waarmee dagelijks miljoenen berichten veilig en betrouwbaar naar burgers en ondernemers kunnen worden verstuurd.

### Vijf stappen

De notificatiedienst ondersteunt vijf stappen in het verzenden en opvolgen van digitale berichten:

1. **Ontvangers bepalen.** Vaststellen wie een bericht moet ontvangen en via welk contactkanaal die persoon of organisatie bereikbaar is.
2. **Berichten versturen.** Het opstellen en verzenden van de notificatie via het juiste kanaal.
3. **Reacties verwerken.** Het vastleggen en verwerken van terugkoppelingen op verzonden berichten.
4. **Contactherstel bepalen.** Signaleren dat een bericht niet aankomt en vaststellen welke vervolgstappen nodig zijn.
5. **Contactherstel uitvoeren.** Het starten, volgen en afhandelen van acties om alsnog contact te leggen.

Een organisatie kan de hele notificatiedienst afnemen, maar ook alleen de onderdelen die zij nodig heeft. Zo sluit de dienst aan op de behoeften die binnen MOZa en OBIS zijn opgehaald bij ondernemers, burgers, overheidsorganisaties en medewerkers van die organisaties.

## Wat de dienst wel en niet doet

De notificatiedienst verstuurt geen officiële documenten. De dienst ondersteunt het digitale proces en informeert burgers en ondernemers dát er ergens een bericht klaarstaat, en waar. Denk aan een melding dat een beschikking, aanvraag of ander document klaarstaat in een portaal.

De dienst is vooralsnog niet geschikt voor het afleveren van het inhoudelijke bericht zelf.

> Een beschikking kan dus niet via de notificatiedienst worden verstuurd, wél het bericht dat er een beschikking klaarstaat en waar die te vinden is.
>
> **Voorbeeld:**  
> een ondernemer ontvangt een e-mail met de boodschap "Er staat een nieuw bericht voor u klaar. U kunt dit bekijken via [naam portaal]."  
> 
> Het bericht zelf haalt de ondernemer vervolgens op in het systeem van de overheidsorganisatie.

## De oplossing

De oplossing start bij de dienstverlener die een notificatie naar de ondernemer of burger wil versturen. De dienstverlener start de notificatie vanuit de eigen procesapplicatie, meestal via een lokaal [outputmanagementcomponent (OMC)](#begrippen) of een vergelijkbare voorziening. De [Notificatie Management Component (NMC)](#begrippen) neemt het vanaf daar over: contactgegevens bepalen, de notificatie laten versturen door Notify, de terugkoppeling verwerken en waar nodig contactherstel starten.

### Via welke kanalen wordt genotificeerd?

Op dit moment richten we ons op één primair kanaal: **e-mail**. In de toekomst kunnen daar kanalen bij komen, zoals fysieke verzending per post, sms, alternatieve digitale berichtenkanalen en andere vormen van elektronische communicatie.

Voor contactherstel wordt fysieke verzending per post straks wél mogelijk. Juist als het digitale kanaal niet werkt, is post de manier om iemand alsnog te bereiken.

### Wie bepaalt naar wie wordt genotificeerd?

De overheidsorganisatie die de notificatie verstuurt, bepaalt zelf hoe de ontvanger wordt vastgesteld. Dat kan op twee manieren:

1. **Decentrale profielservice.** De dienstverlener heeft een eigen profielservice en bepaalt daarmee zelf wat de contactvoorkeur is en welke gegevens daarbij horen. Worden die gegevens meegegeven, dan gebruikt de notificatiedienst ze bij het verzenden. Ook als er in een centrale profielservice andere gegevens beschikbaar zijn.
2. **Centrale profielservice.** Er is één centrale plek waar contactvoorkeuren en bijbehorende gegevens worden vastgelegd. Op basis van een identificerend nummer zoals een KVK-nummer of BSN kan het juiste contactgegeven worden opgehaald.

Het heeft de voorkeur om zoveel mogelijk gebruik te maken van de [centrale profielservice](/onderwerpen/profielservice/index.md). Contactgegevens zijn dan eenvoudiger te beheren, informatie kan centraal worden bevraagd en processen zoals contactherstel zijn centraal te organiseren.

### Verzending en terugkoppeling

Geen enkele e-maildienst kan garanderen dat een bericht daadwerkelijk door de ontvanger is gelezen. Daarom geldt: is een bericht succesvol afgeleverd bij de mailserver van de ontvanger, dan beschouwen we dat als een succesvolle verzending.

De notificatiedienst koppelt per functionaliteit terug wat de status is. De verzendende organisatie weet daardoor steeds waar haar notificatie in het proces staat. Die terugkoppeling bestaat uit twee delen:

1. **Wat is de huidige status,** en wat is er eventueel al opgevolgd? De dienst meldt dat het bericht is verzonden en meldt problemen zodra ze zich voordoen. Dat kan uitmonden in de terugkoppeling dat verzending niet is gelukt en dat wordt overgegaan op contactherstel.
2. **Wat gebeurt er hierna,** als er geen tegenbericht komt? Bijvoorbeeld: "notificatie verzonden, we wachten 48 uur". Komt er tussentijds een softbounce binnen, een melding dat de e-mailserver tijdelijk onbereikbaar is, dan volgt "softbounce ontvangen, nieuwe poging over 3 uur". En uiteindelijk mogelijk: "notificatie niet afgeleverd, contactherstel via post gestart".

Voorbeelden van statussen die kunnen optreden:

* contactgegeven niet gevonden, alternatief adres nodig
* notificatie verzonden
* tijdelijke afleverfout, nieuwe poging gepland
* notificatie niet afgeleverd
* contactherstel gestart via post
* contactherstel afgeleverd

Dit zijn voorbeelden. De lijst vullen we verder aan naarmate we de dienst samen met dienstverleners vormgeven.

### Wat gebeurt er als een notificatie niet aankomt? En wie bepaalt de vervolgstappen?

Soms kan een notificatie niet worden afgeleverd, bijvoorbeeld omdat een e-mailadres niet meer bestaat of niet bereikbaar is. Dan kunnen er herstelacties nodig zijn. Bij notificeren onderscheiden we er twee: procesherstel en contactherstel.

#### Procesherstel

Het niet kunnen afleveren van een notificatie heeft mogelijk gevolgen voor het onderliggende proces. Of dit zo is, dat wordt vastgesteld door de dienstverlener. De dienstverlener bepaalt bijvoorbeeld of een bericht opnieuw moet worden verstuurd, of een proces moet worden gepauzeerd, wanneer vervolgacties nodig zijn en welke gevolgen een mislukte aflevering heeft. Dat noemen we **procesherstel**: het verder oppakken van het proces waaraan de notificatie is gekoppeld.

Een voorbeeld maakt duidelijk waarom dat bij de dienstverlener hoort:

* Een proces richt zich op de btw-aangifte.
* Dat proces leidt tot een beschikking, die bekend moet worden gemaakt aan de ontvangers. Onderdeel daarvan is een notificatie over die beschikking.
* In de beschikking staat dat er een bedrag betaald moet worden.

Om te bepalen wat het betekent dat de notificatie niet is aangekomen, is kennis van dat proces nodig. Zijn er meerdere ontvangers, en hebben die de notificatie wel gekregen? Is het bedrag inmiddels betaald, en maakt dat uit voor de vraag of opnieuw verzonden moet worden? En als er niet is betaald: per wanneer komt daar een boete bij?

De notificatiedienst heeft in de meeste situaties verder geen rol meer in het **procesherstel**.

#### Contactherstel

Het feit dat een notificatie niet kan worden afgeleverd, betekent in veel gevallen ook dat contactherstel nodig is. Ofwel, we starten een proces op waarmee we de ondernemer of burger vragen om hun contactgegevens bij te werken. Het doel daarvan is dat de burger of ondernemer het digitale adres corrigeert, zodat toekomstige notificaties weer aankomen.

Voordat contactherstel start, stellen we eerst vast hoe de verzending is verlopen. Het initiëren van contactherstel is dus niet een proces dat automatisch in gang wordt gezet. Ook hier is er interactie met de dienstverlener. De dienstverlener bepaalt daarbij bijvoorbeeld zelf hoe het contacthersteladres wordt vastgesteld. Dat kan op twee manieren:

1. **Via de dienstverlener zelf.** Net als bij het initiëren van de notificatie kan de dienstverlener het contacthersteladres zelf meegeven. Dat kan direct bij het initiëren van de notificatie, of het adres wordt op dat moment actief bij de dienstverlener opgehaald. Onze voorkeur gaat uit naar het tweede, omdat dat beter past bij het principe van dataminimalisatie.

2. **Als onderdeel van de notificatiedienst.** Kiest de dienstverlener daarvoor en zijn er voldoende gegevens beschikbaar, dan kan de notificatiedienst zelf contactherstel starten en een adres bepalen. Bijvoorbeeld op basis van een KVK-nummer, RSIN of BSN.

> Op basis van een pseudo-id of een ander kenmerk van de dienstverlener is geen adres te herleiden in centrale bronnen. Heeft een dienstverlener geen officieel kenmerk, dan kan de notificatiedienst het contactherstel niet zelf organiseren. De dienstverlener kan de contactherstelgegevens dan wel bij de aanroep meegeven.

We onderzoeken of contactherstelacties voor hetzelfde contactgegeven periodiek gegroepeerd kunnen worden, zodat de ontvanger daarover één bericht krijgt in plaats van meerdere. Dat scheelt post aan mensen van wie het e-mailadres niet meer werkt.

De notificatiedienst houdt bij dat contactherstel is gestart en stelt ook vast wanneer het is afgerond. Na een bepaalde periode worden die gegevens weer verwijderd.

### Dataverwerking

Bij het versturen van berichten worden gegevens verwerkt. Op basis van de standaard [Logboek Dataverwerkingen](https://www.logius.nl/onze-dienstverlening/gegevensuitwisseling/logboek-dataverwerkingen/wat-is-logboek-dataverwerkingen) leggen we vast welke verwerkingen binnen de notificatiedienst hebben plaatsgevonden.

## Uitgangspunten

Bij het vormgeven van de notificatiedienst hanteren we de volgende uitgangspunten:

* **Functionaliteit is leidend,** de techniek volgt daaruit.
* **Zo snel mogelijk meerwaarde bieden** voor zoveel mogelijk dienstverleners.
* **De aansluitdrempel is zo laag mogelijk** voor alle dienstverleners.
* **De regiekeuze blijft bij de dienstverlener.** Die bepaalt zelf welke functionaliteiten er gebruikt worden.

### Centrale en decentrale regie

Er is behoefte aan zowel centrale als decentrale regie op notificeren.

Decentraal ligt regie voor de hand bij het koppelen van notificaties en statussen aan een klantcontactsysteem, het besluit tot herverzending, en de koppeling met procesherstel. Een decentraal OMC kan die rol goed invullen, maar een dienstverlener kan dit ook anders organiseren.

Centraal ligt regie voor de hand bij het ontzorgen van het notificatieproces, zodat dit vanuit een overheidsstandaard steeds op dezelfde manier verloopt. Ook het uitvoeren van contactherstel hoort daarbij, zodat niet elke dienstverlener afzonderlijk contactherstel hoeft te starten. En het bepalen van ontvangersgegevens, waarbij meerdere bronnen een rol kunnen spelen, zoals de profielservice, de Basisregistratie Personen (BRP) en het Handelsregister (HR).

Van sommige functies is nog niet duidelijk of ze logischerwijs centraal horen. Die kunnen mogelijk ook decentraal worden belegd. Dat verkennen we in samenhang, aan de hand van concrete use-cases.

De NMC heeft uitdrukkelijk niet de bedoeling om decentrale OMC's te vervangen. De NMC ontstaat ernaast. Het bestaande OMC is ontwikkeld voor gemeenten, binnen Common Ground en MijnServices. De NMC bouwen we als een voorziening om centrale processen te regisseren. Daarbij bouwt de NMC voort op het OMC. Deze aanname toetsen we periodiek opnieuw.

### Moderne overheidsstandaarden

De notificatiedienst gebruikt moderne overheidsstandaarden, waaronder [Federatieve Service Connectiviteit (FSC)](https://fsc-standaard.nl/), [Logboek Dataverwerkingen](https://www.logius.nl/onze-dienstverlening/gegevensuitwisseling/logboek-dataverwerkingen), de [NeRDS-principes](https://minbzk.github.io/NeRDS/) en de [API-standaarden](https://developer.overheid.nl/kennisbank/api-ontwikkeling/standaarden/). Daardoor kunnen overheidsorganisaties hun bestaande systemen eenvoudig aansluiten. De dienst ondersteunt niet alleen het versturen van berichten, maar ook het terugkoppelen van bezorginformatie en het uitvoeren van vervolgacties zoals contactherstel.

### Afsprakenstelsel

Over de dienstverlening maken we duidelijke afspraken, vastgelegd in een [afsprakenstelsel](https://www.logius.nl/onze-dienstverlening/afsprakenstelsels). Aangesloten organisaties weten daardoor vooraf wat zij kunnen verwachten.

Organisaties kunnen ook gebruikmaken van een speciale aansluiting. Is daar een juridische grondslag voor, dan kunnen zij een bericht versturen op basis van een identificerend nummer zoals een BSN of KVK-nummer. De notificatiedienst haalt dan via de centrale profielservice de voorkeurscontactgegevens van de ontvanger op, en verstuurt het bericht automatisch via het juiste kanaal met het juiste berichtsjabloon. Zo komt belangrijke informatie sneller en betrouwbaarder aan, via het kanaal dat de ontvanger zelf heeft gekozen.

## Vervolgstappen

We ontwikkelen de notificatiedienst verder. Op de agenda staan:

* Het toevoegen van kanalen naast e-mail.
* Het toevoegen van alternatieve informatiestromen binnen de overheid.
* Het toevoegen van inhoudelijke aflevering, dus het bericht zelf en niet alleen de notificatie erover.
* Onderzoek naar tweerichtingsverkeer. Naast het versturen van notificaties ligt de vraag op tafel wat er nodig is voor communicatie in twee richtingen, en welke rol de notificatiedienst daarin speelt.

## Onze werkwijze

Bij de ontwikkeling volgen we de [werkwijze](/handboek/werkwijze/) en [principes](/handboek/werkwijze/principes/index.md) van MOZa. We zoeken actief de samenwerking op, hanteren open standaarden en treden op als betrouwbare partij waar privacy en transparantie hoog in het vaandel staan. Al bij het ontwerp denken we na over minimale dataverwerking en het vastleggen van gegevensverwerkingen.

## Meedoen

De notificatiedienst bouwen we samen met overheidsorganisaties. De dienst heeft alleen waarde als organisaties meedoen, dus we nodigen je uit om mee te denken, mee te bouwen en kennis te delen. Hiervoor organiseren we ook maandelijkse werksessies waarin we samen met elkaar aan deze dienstverlening werken. Benieuwd? Sluit je aan en [praat met ons mee!](/contact/index.md)

## Begrippen

**Dienstverlener.** Alle overheidsinstanties, zoals gemeenten en uitvoeringsorganisaties, die als overheidsinstantie notificeren richting burgers en ondernemers.

**Procesapplicatie.** Ook wel vakapplicatie. De applicatie die het functionele proces uitvoert of regisseert vanuit de dienstverlener. Deze bepaalt dat communicatie nodig is, en in welke vorm. In de context van de notificatiedienst start deze applicatie de notificatie, eventueel via een lokaal OMC. Ook procesherstel wordt hier georganiseerd.

**Outputmanagementcomponent (OMC).** Decentraal component dat binnen het domein van de dienstverlener de regie voert op het notificatieproces en lokale koppelingen kan leggen.

**Notificatie Management Component (NMC).** Het component dat vanuit centraal oogpunt invulling geeft aan de vijf functionaliteiten van de notificatiedienst. Een dienstverlener kan alle vijf functionaliteiten afnemen, of alleen de onderdelen die nodig zijn.

**Decentraal profiel.** De gegevens van een burger of ondernemer die een dienstverlener lokaal heeft staan. In de praktijk kan dat uit meerdere applicaties of informatiebronnen bestaan.

**Centraal profiel.** De gegevens van een burger of ondernemer die centraal worden opgeslagen. Ook dit kan in de praktijk uit meerdere bronnen bestaan.

**Notify.** De centrale verzendcomponent van de notificatiedienst, inclusief templating. Hiervoor zetten we de opensourcecomponent [NotifyNL](https://github.com/Worth-NL/notifynl-api) in.

## Meer info

* [Code op GitHub](https://github.com/MinBZK/moza-notificatiemanagementcomponent)
* [Uitgewerkte flow van de notificatiedienst (sequence diagram)](https://sequencediagram.org/index.html#initialData=C4S2BsFMAIDkHtQDMQGMCGpIBMSQHYDOwS48A7tAIwDsAtAGx0BMADMw9ABQAyAogBVoAeQAKAGmiQATtADW6fNGwBXQlILR8eFeRgA3GYTzQAXiABWSutFQALSKjnR9IdNAC28U+gACAI1M5ADp8cABKACgAB3RpUFQQWPxgAHNpeBVo6AARPCJgQ2kofBloAHpcxwJgaXR0cBi4hKTFYGhRDNRIQnRo6PA0TDwm+LRWlOgAIRk0O2ACf3gAD1GW5PbReHiGtfGN3IBhTvgUSEbYscSD4QBZQ8iCbD3rtvTM7MOauqhc-OIXhM0hksnBECAUN1pARAQdYPdIrC2tABJAPANhvhUkjJghkABPHHtQ7wFLoVDABzSYjnRGXdbIzogFLEOqYR74Z70-aMjJncCEGSubpE6AAaX0YvKUwASqIOVzmjzJrd0CBwNAAMpCmSirbEdDYaGESLk4DbDpGeCk00UkD6TAwE7dXr9QYYLCRfCIGDwIodLo9PoDIZYSRbHYagDcAGYo9h0IQHNgAFwASXA4DUtWGkCQKYAOvg8u0QOp4NFQKTIOdoDZNAolBjMIRXJyCEX9Na6khUvVOdB+9AHO0isQVNClA6lDX8EXvchQyNIhX2lRprN7At8EtVs6g26lzA6AA+GbSObb3cpjrgerAQVKZl2TLYc6WZz+TfzIsKleV6BmBEMJmSdbZgF2fdXRDD0TFPCMIPAG9RDvFtNGfV93wsT9v2AX8nkRREoODd1czrE9iMPWDIBvGZYhKaAvxfPMFk7bstHBSFc0id5QTxCEj2Uf5gERXjsioYJoAACUgdov3ozRp2UX0UmnVJiC7bY5EgCdoAAS6UCs7AaTR-EsJjtieFTCkUdS0kgVJIEMIgiMDaDSKwciRHuG8020UAAGvJ1seAPA8FRtGo21QAdBZvIeBp2hyaoUh+GBoVSZdEugL5UpM6Boj5PANUFaRhUgRE7kOeCivOUrypvYRomMhjNOkbTdPgfx9BvIsbAlMVoAAag6QUVGweA02wCpoBlTU01gSopk1WA+r+AgNJkEoZDWvINpEs17UdANTmK+q0Aq7KqEiE5+XO7pyKqm8AHFZ2gRzHOc9Qv0IewQDkfx6mkP9suYG7aoFIULsenyctJCCKTajrpBvNE1XAIs0fVG9mSQeAAhwC8LCQUJGgIt9Dtip0IfuiqCOy5LujyhoCohyr7nInJjghlMmpaxTu2R6Aup66A1oG4bRp0iappmuaFqWlbduEoptukZX9uio64q527isRXWIZhw4bxJMlEcFnSUakDx0cx23segXH8a-I1LBJsJIgpu0qaOPXaQI9nqpPJ6NwUpRHP8aQVH+lxFE7GRTCeD6nI2xF6fAYlvnyjKRiq094RN6A-LAEAgs0VBQvCyKyJFwt8DFAA1KV5cW5bVvwLXfcLyJC-I-3IbKi7Guakyp0tzrut6-B+slSXRDGmXpsqVvFY7mw9oKVWCB2mf1oKLvjoH2nwdOuqoYe084Fhs2EcKCfraxjHSgdpCnfwPGCbd4nSb-RFKeOlVf+Psj40wvhVb2MVQFn0HuVYBUCdbcxgYiSB2sYCG2Qag32QC-5iUApJGS7RegeH2ucBimgEyGj0O1LCzgihJ3bFORQykOKLiitlJmOZfi5wqoXAuPkS5YDKPQp4zJsQZ3aG+ThaVoA8MiFVcihdfL+TLsFBcAlqKeFksoIGzJ66zzFPgWQI1oiL0msvVuM124ay3ltHe6s96b2IGtAQ+JogGETqIrE09oB1mgAAMXxMYSAchyhPzWnwV+OMP4u0Ju7UmLi3EwC-BeLca1zyXkIO4xIZxtLvzxtIW2WB65+JyJgFQHguCECiARPup5UTojvKAbxIhR4MQWI0zEqRhZT0Se4xiuFD5xQaRiZp2IRlNLEV5JR0BG5GHsOgJASBNAdNGRAyAADhlolGWI3uHMr4zKajSTMplcL6NmSoE5ShVlNMgGtTU6ASEFDIac1J8w9mHEUZxfEyjS7lynJ4zkuzNkwH4kgQkYL8ReVVOqLUOprZzOpMACcrzLxDJgDCjU2oyq6lEFaUkdYr6YrhTi62PBIAMLFjuQZgc8ExmktoisalNCaFzqyGQilmHGmiKSQU6g7B4AyNEf+mctQqFQC6LsjRiXYv9AXb5N5NQQWReoNgrBe7fOmbDRF45gqEHFZK+AjQ6knhmY3RMEAHKOSUNy3ldNOSmlFbAPARCDU9Clb8RZUAihTOujK+FXyCSNVUrZTQeMVDAErm+dQ9zlVqGgAAVmCMsZNwRY3lPUAAFlTSmr2GyQFxX9aSjVBItVFx1citRLroD6ole6o1Hz+FFzomPDi8BsA+HQM4IsVIRFAqxFSrgZkLCMUsPoaA4bI3tpgNmlNKaohYOOpCkVWc8rcIciME1x9wHKIdIMN8wUn50ENMaEGorGbZ3XZlXh9xTyhwrSipQWQExxQ8P4doXrU4XgHQAMhtujE9PR0XxXkbek8GD+S7oaCAA9mhX6AZNARJDDqeIgmyNmhlclIDhzjkoSu5tKRGAWBqUy5lIAvknG+YWIasTEBTl9R1q6uEwBlBum9wcZktoYt6dtnbnCaEEaoiu8MzRUmOSUvxA06D4AqSQ2QpxpgrQGb9AVAMgbQA+f3MBQ9ug3lgOgPszD8N3zE8R1ceATQgpOndcBp8bM6ePCea+RdXrOWFpWCzRYuCNmFvAZwjlNDmZgOYKwUQ+EnlvqJoj5xfmBWCsZs0w5osai4CLXD4pJTSiUwAZ6QKOiwFlKPvQcqnTuVnIsUlM7SCrhGkW1lPDVqrb8uOKSFEauyfR-ztD5q28FwTnAIciI15L5EBrSjlCPfmSg+t4AG0aIDVmxuynlEtuU5Fht1bfjqhZSzNCDcXXFVb8pkPPDzVZ7dDngNHbOwWmA12JG+IvWu9KbHQPB3irRbDraeMdvqHIIsCXKvJd-AzFKOYWaFWQfncDSDINwAM0OQHtXjn0bTlZiD+sMf1ZDtq+ZxldsRxKwxg76DYf6we7lcHGpIf8je1pmBtM9MI6MyJoHm3UcuXO9puBF3ypeXvXjxZyzCefQ2twZkuBTkqf+oDOIf4TuiTQ4mgh2iY73w5TOQy0QpXWvS0jprK6qjSJzq9hRTbYtCbw6z5HxGek9XFpKIxktTHS3MRUSxa8bGbWKPYtaG3jl9I8dIBhuAWlFl8TYQJ-WwmvwiVE-JsTv4e2fjYVx-SUmXnSbhLJjgBIhJgM7QpuYSkb3KZU6pv4ScgYp5el716hvW6a15f3tuLf-JCnlNnxy-4MxAJlRCQeQ9TP18lzT9TtmTJaT1hiI-NtFhuY6EHt2UQT66ZECZXTFG4+pDt4X0AF8LBuwgmAG+xlj6c4c0xxGGIZ63Ocxulz2mr9YnvB5Tzjk39wgWc-kK2-BT7aHtiFZsupCtCujCSkUDeA+sFLfu8lZkWkUDdPitYESuAbKjIDeOSpSkWLASJIxmKnWq2A2ggWUPKkGlqHGqqqwOqqAQctvrqpoLWoasavsqatqhalAKkLrrakQPas8NlM6tokwfWicoOKQF+rsiQbIGQRCD8sBDZFiGGpkFOtGlSjYEqhmsrnOmmq-pQdALOqmigvmsftAFISWrIWWlAURo+loNWsIUQY0FXsuunA6tlJTjInIlutzsPMXPgHujBhrv+uqMevNohihqDsblepumBqHK5owZQc+o6MBkAvnKeFjm-AAKrRAvrCYEZUhz6KGi4uQK7ZRR6zaD5eLdKz7d5uG16yKvYt7Y5wx5HJafY4bVHEZFgzYhLQB-rmhfaECPjFZFGWbL7XZV73auGipSJ1FyLQ6hwtZKA-Z8Yd4mYjbdFyB05pFk4xbT6srnBORtAwAc6jEmHpGRDpH870G76aAnFH5oJ+xsxm5sFFyCY1iyAbGrFRYFEjTDqFZWTDGlYmhV5AL0xjGZbLb3G+zXYN4tGbbkSn5iKTatodHnDz7P6XTL6IlYjr7P5TINaN6tGzKC4E774YlQnHTYnYiwlrHwk1TMgPjg7AA3g5DdhJzADbguDdhdFBLlEuCAqAHAZMgshMngwMmsj3j9zwAGihFWFIo2H4BAxFiDbCmMlsjtAElwniYbiGDEB95TIJzB6VEUlxSqkSnsh4rUjWgoEUTSkQSynQBYGoppKIiNEajm46k9CgCZQDoAG7JV5un4HuEm717hZmocFWoEDTzqF6F+kDpcCORZhyDADlDaDaKJkqDJnhBrQ8DwBcH+nGEPE9y1KsEfbEk774576JGH5WZALZQzHPb1H17zGwy5n5kDp2Axy4COQ1qUH4QOoK7PGUQwTF65BsmyScnVnrK1kIiByESuTwAugkSCQ1SLkHgjnFJhzfbWi-ZdqGk66HSQBVLhDnIySkpD5Yjf6RBAA)
* [Technische documentatie](https://docs.mijnoverheidzakelijk.nl/workspace/documentation/Notificatiedienst)
* [NotifyNL op GitHub](https://github.com/Worth-NL/notifynl-api)
* Lees ook over de [profielservice](/onderwerpen/profielservice/index.md), waar contactgegevens en voorkeuren worden vastgelegd

## Profielservice

## Huidige uitdaging

Overheidsorganisaties (dienstverleners, gemeenten) slaan contactgegevens en voorkeuren los van elkaar (decentraal) op. Burgers en ondernemers voeren daarom dezelfde gegevens steeds opnieuw in bij verschillende portalen. Dat kost tijd en leidt tot fouten. Daarnaast worden op verschillende plekken dezelfde functionaliteiten (door)ontwikkeld. Een centrale profielservice biedt de oplossing. Daarmee bereiken we:

* **Voor burgers en ondernemers:** je kunt je gegevens vanuit verschillende portalen aanpassen, maar ze worden centraal op één plek opgeslagen. Minder administratie, betere communicatie.
* **Voor overheidsorganisaties/dienstverleners:** je krijgt actuele en betrouwbare gegevens uit één centrale bron.
* **Voor de digitale overheid:** een herbruikbare bouwsteen die past binnen de [Generieke Digitale Infrastructuur (GDI)](https://www.digitaleoverheid.nl/mido/generieke-digitale-infrastructuur-gdi/).

## Wat is de profielservice?

De profielservice is een centrale plek waar burgers en ondernemers hun contactgegevens en voorkeuren met de overheid beheren. Denk aan: wil je e-mail of post? En op welk adres? Je stelt je voorkeuren in vanuit een portaal, en ze worden centraal opgeslagen. Alle aangesloten overheidsorganisaties gebruiken dezelfde gegevens. Wil je iets wijzigen? Dat kan vanaf elk portaal en de nieuwe gegevens zijn direct beschikbaar.

## De oplossing

Hieronder lichten we de belangrijkste uitgangspunten van de profielservice toe en hoe deze werkt voor burgers, ondernemers en overheidsorganisaties.

### Gegevens vastlegging

De profielservice werkt met drie begrippen: een **identificatie**, een **contactgegeven** en een **voorkeur**. Elke vastlegging koppelt een contactgegeven of voorkeur aan een identificatie (de unieke 'sleutel' om gegevens terug te vinden).

* **Identificatie**: hoe ben je uniek herkenbaar? Denk aan BSN, KVK-nummer, RSIN of een ander identificerend nummer.[^identificatie-personen]
* **Contactgegeven**: waar kun je worden bereikt? Denk aan een specifiek e-mailadres, postadres of telefoonnummer.
* **Voorkeur**: hoe wil je worden bereikt? Denk aan voorkeur voor e-mail boven post, of in welke taal je liever leest.

[^identificatie-personen]: Bij de toepassing bij personen in relatie tot ondernemingen bestaat de identificatie uit twee onderdelen: een persoonskenmerk (bijvoorbeeld BSN) en een organisatiekenmerk (bijvoorbeeld KVK-nummer of RSIN). Dit kan dus naast de koppeling KVK-nummer-contactgegeven bestaan.

### Type gegevens

De profielservice bevat alleen gegevens die nog niet ergens anders zijn vastgelegd én die dienstverleners helpen hun primaire processen beter uit te voeren. Concreet gaat het om contactgegevens (zoals e-mail of postadres) en voorkeuren (zoals contactmedium of taal). Persoonlijke kenmerken zoals pasfoto's slaan we niet op.

### Koppeling

De unieke vastlegging wordt gekoppeld aan een **dienstverlener** en eventueel een **dienst**:

* **Dienstverlener** is bijvoorbeeld *Gemeente Amsterdam* of *Belastingdienst*.
* **Dienst** wordt vastgesteld door, en is daarmee altijd gekoppeld aan, een **dienstverlener**. Voorbeelden hiervan zijn Zorg (binnen Amsterdam) of Omzetbelasting (binnen Belastingdienst).[^dienst-niet-verplicht]

[^dienst-niet-verplicht]: Een dienst is niet verplicht. Een contactgegeven of voorkeur kan ook alleen aan een dienstverlener gekoppeld zijn.

Een burger of ondernemer kan contactgegevens en -voorkeuren instellen per dienstverlener, en optioneel per dienst. Binnen een dienst is geen verdere onderverdeling mogelijk. Zo voorkomen we dat iemand voor verschillende onderdelen binnen één dienst aparte voorkeuren moet beheren, wat in de praktijk al snel honderden combinaties zou opleveren.

### Hergebruik gegevens

Een ondernemer kan bij meerdere bedrijven betrokken zijn. En een bedrijf kan meerdere contactpersonen hebben. Daarom kun je met de profielservice per bedrijf andere contactvoorkeuren instellen. De profielservice slaat contactvoorkeuren op per combinatie van persoon en bedrijf. Dit heet een N:M-model: veel personen kunnen gekoppeld zijn aan veel bedrijven. Een overheidsorganisatie vraagt het contactgegeven op voor een specifiek bedrijf en krijgt de gegevens van de juiste contactpersonen terug.

```mermaid
---
title: N:M-model Profielservice
---
graph LR
  accTitle: N:M-model Profielservice
  accDescr: Meerdere personen kunnen gekoppeld zijn aan meerdere bedrijven (N:M-model). Elke pijl symboliseert een contactgegeven en/of voorkeur.
  P1@{ icon: "tabler:user", label: "Persoon A" }
  P2@{ icon: "tabler:user", label: "Persoon B" }
  P3@{ icon: "tabler:user", label: "Persoon C" }
  B1@{ icon: "tabler:buildings", label: "Bedrijf 1" }
  B2@{ icon: "tabler:buildings", label: "Bedrijf 2" }
  B3@{ icon: "tabler:buildings", label: "Bedrijf 3" }

  P1 <-->|contactgegeven/voorkeur| B1
  P2 <--> B2
  P2 <--> B3
  P3 <-->|contactgegeven/voorkeur| B3
```

In dit diagram staat elke pijl voor een contactvoorkeur. Persoon A is betrokken bij één bedrijf en heeft één contactvoorkeur. Persoon B is betrokken bij bedrijf 2 én bedrijf 3. Voor elk bedrijf kan persoon B een ander contactgegeven en/of voorkeur instellen. Bedrijf 3 heeft twee contactpersonen: persoon B en persoon C.

### Verificatie contactgegeven

De profielservice kan een contactgegeven verifiëren. Wordt er een nieuw contactgegeven toegevoegd dat nog niet is geverifieerd, maar dat we wel willen verifiëren? Dan start de profielservice de verificatie automatisch.

> Op dit moment is verificatie alleen mogelijk voor het contactgegeven e-mail.

Heeft een dienstverlener het contactgegeven al zelf geverifieerd? Dan geeft die dat door bij het toevoegen of wijzigen. De profielservice start dan geen nieuwe verificatie.

### Hoe werkt dit voor burgers en ondernemers?

```mermaid
---
title: Klantreis burger of ondernemer
---
graph LR
  accTitle: Klantreis burger of ondernemer
  accDescr: De stappen die een burger of ondernemer doorloopt: inloggen met DigiD, eHerkenning of eIDAS, gegevens bekijken, contactvoorkeuren instellen.
  A@{ icon: "tabler:login", label: "Inloggen met DigiD, eHerkenning of eIDAS" }
  B@{ icon: "tabler:user", label: "Gegevens bekijken" }
  C@{ icon: "tabler:address-book", label: "Contactvoorkeuren instellen" }
  D@{ icon: "tabler:check", label: "Klaar" }

  A --> B --> C --> D
```

Je logt in met DigiD, eHerkenning of een Europees inlogmiddel (eIDAS), bekijkt je gegevens en stelt je contactvoorkeuren en bijbehorende gegevens in. Dat is alles. Je hoeft dit niet meer apart te doen bij elke overheidsorganisatie; je past het centraal aan.

### Hoe werkt dit voor overheidsorganisaties?

Er zijn twee toepassingen:

#### 1. Indirect gebruik door instanties

In dit geval wordt de profielservice gebruikt binnen het notificatieproces. Een overheidsorganisatie geeft alleen aan naar wie en wat er verstuurd moet worden, en de notificatiedienst zoekt via de profielservice op hoe en waarop de ontvanger het liefst benaderd wordt.

```mermaid
---
title: Bestuurlijk bericht versturen
---
graph LR
  accTitle: Bestuurlijk bericht versturen
  accDescr: Een bericht wordt klaargezet in het berichtenmagazijn. De notificatieservice zoekt de contactvoorkeuren van de burger of ondernemer op en verstuurt een e-mail of brief.
  A@{ icon: "tabler:inbox", label: "Bericht klaarzetten in berichtenmagazijn" }
  B@{ icon: "tabler:bell", label: "Notificatieservice" }
  C@{ icon: "tabler:address-book", label: "Contactvoorkeuren opzoeken in profielservice" }
  D@{ icon: "tabler:mail", label: "E-mail verstuurd" }
  E@{ icon: "tabler:mailbox", label: "Brief verstuurd" }

  A --> B --> C
  C -->|e-mail| D
  C -->|post| E
```

Een overheidsorganisatie zet een bestuurlijk bericht klaar in het berichtenmagazijn. De notificatiedienst zoekt via de profielservice het contactgegeven en/of voorkeur van de burger of ondernemer op. Bij voorkeur voor e-mail gaat er een e-mailnotificatie uit dat er een bericht klaar staat. Dit bericht kan daarna in een berichtenbox gelezen worden. Bij voorkeur voor post wordt er een brief verstuurd. Zo bepaalt de burger of ondernemer zelf hoe die wordt bereikt.

#### 2. Direct gebruik door instanties

In dit geval bevraagt een overheidsorganisatie de profielservice rechtstreeks om te bepalen hoe zij een burger of ondernemer kan bereiken.

```mermaid
---
title: Klantreis overheidsorganisatie
---
graph LR
  accTitle: Klantreis overheidsorganisatie
  accDescr: De stappen die een overheidsorganisatie doorloopt: aansluiten via FSC, voorkeuren ophalen, de burger of ondernemer bereiken.
  A@{ icon: "tabler:plug-connected", label: "Aansluiten via FSC" }
  B@{ icon: "tabler:address-book", label: "Voorkeuren ophalen" }
  C@{ icon: "tabler:mail", label: "Burger of ondernemer bereiken" }

  A --> B --> C
```

Overheidsorganisaties sluiten eenmalig aan via [Federatieve Service Connectiviteit (FSC)](https://fsc-standaard.nl/) en [Federatieve Toegangsverlening (FTV)](https://vng-realisatie.github.io/ftv/). Bij elk contactmoment halen zij de contactvoorkeuren van de burger of ondernemer op en bereiken zij de burger of ondernemer op de manier die deze zelf heeft gekozen.

## Huidige status

We brengen de profielservice naar een bètaversie, waarbij we zowel de techniek als de juridische kant waarborgen. We pakken dit stap voor stap aan.

Wat de profielservice technisch kan, is meer dan wat we nu functioneel inzetten. Die grens wordt bepaald door het juridische proces.

De eerste versie richt zich op de functionele toepassing binnen het notificatieproces, zoals aangeboden in de [notificatiedienst](/onderwerpen/notificatiedienst/index.md).

Hieronder beschrijven we eerst de functionele inzet, daarna de bredere technische mogelijkheden.

### Functioneel

In deze eerste versie ondersteunt de profielservice de volgende functionele toepassingen:

1. Een burger of ondernemer kan via een overheidsportaal de voorkeur (e-mail of fysiek) en eventueel bijbehorende gegevens (e-mailadres) invoeren.
   * We willen hierbij zoveel mogelijk uitgaan van één e-mailadres dat overheidsbreed bruikbaar is.
2. Wanneer er een notificatie verstuurd moet worden, bevraagt de notificatiedienst de profielservice. De overheidsinstantie moet daarbij de identifier(s) meesturen waaronder de ontvanger in de profielservice bekend is.

> Er wordt onderzocht welke (juridische) opties we hebben, en wat er daarvoor georganiseerd moet worden, om ook het directe gebruik van de profielservice door een overheidsinstantie te faciliteren.

### Technisch

In deze eerste versie kijken we verder dan alleen deze functionele toepassing. Vanuit de techniek zijn de volgende zaken ingeregeld:

* Koppelen van unieke identifiers (**identificatie-contactgegeven** en **identificatie-voorkeur**) aan de verschillende overheidsorganisaties en eventuele specifieke diensten.
* Mogelijkheid tot het instellen van een primaire voorkeur.
* Mogelijkheid tot het instellen van verschillende voorkeuren, waaronder:
  * SMS
  * App-id's
  * Taal
* Mogelijkheid tot het verwijderen van gegevens (gekoppeld aan specifieke uitgangspunten).
* Mogelijkheid tot het opvragen van informatie, ook door derde partijen (onder andere als onderdeel van [Federatieve Service Connectiviteit (FSC)](https://fsc-standaard.nl/) en [Federatieve Toegangsverlening (FTV)](https://vng-realisatie.github.io/ftv/)).

## Vervolgstappen

We blijven de profielservice verder ontwikkelen, waarbij we ons nu richten op:

* Voorbereiden op beheer door Logius
* Verfijning van functionaliteiten, zoals het verwijderen van gegevens

Voor de volledige en meest recente backlog, bekijk de taak ["Profielservice" op GitHub](https://github.com/MinBZK/MijnOverheidZakelijk/issues/24).

## Onze werkwijze

Bij de ontwikkeling volgen we de [principes](/handboek/werkwijze/principes/index.md) van MOZa. We zoeken actief de samenwerking op, hanteren open standaarden en treden op als betrouwbare partij waar privacy en transparantie hoog in het vaandel staan. Al bij het ontwerp denken we na over minimale dataverwerking en het vastleggen van gegevensverwerkingen.

## Meedoen

De profielservice bouwen we samen met mensen uit diverse organisaties en vakgebieden, van beleid en ontwerp tot juridisch en techniek. Want deze voorziening heeft alleen waarde als alle overheidsorganisaties meedoen. We nodigen je uit om mee te denken, mee te bouwen en kennis te delen. Benieuwd? Sluit je aan en [praat met ons mee!](/contact/index.md)

## Meer info

* [Voortgang en broncode op GitHub](https://github.com/MinBZK/moza-profiel-service)
* [Technische documentatie](https://docs.mijnoverheidzakelijk.nl/workspace/documentation/Profiel%20Service)
* Uitproberen in [het portaal MijnOverheid Zakelijk](https://moza.mijnoverheidzakelijk.nl/) als onderdeel van [de proeftuin](/onderwerpen/proeftuin/index.md)

## Open werken

Het programma MijnOverheid Zakelijk gebruikt verschillende platforms en tools om zo transparant mogelijk te kunnen werken. Zo ondersteunen we het "open werken"-principe. We werken samen met verschillende overheden in actieve dialoog om services te ontwikkelen die van toegevoegde waarde zijn. Ook betrekken we zoveel mogelijk eindgebruikers in het ontwerp- en ontwikkelproces. Bijvoorbeeld via UX-onderzoek en co-creatie.

Via het GitHub-platform werken we samen aan documenten, software en beleidsproducten. Besluiten en technische keuzes zijn terug te lezen in commits, issues en merge requests. Externen kunnen meedenken via issues, suggesties of pull requests.

We publiceren software, data-scripts of standaarden als open source. Andere organisaties kunnen dit hergebruiken → minder dubbel werk. Kortom, we werken niet achter gesloten deuren, maar samen en zichtbaar. Iedereen kan zien wat er verandert, door wie en waarom.

Wil je meekijken of meedoen? [Kijk dan op onze GitHub](https://github.com/orgs/MinBZK/teams/mijnoverheid-zakelijk/repositories).

## Proeftuin

Een overzicht van alle beschikbare tools, applicaties, documentatie en relevante links van MijnOverheid Zakelijk.

## Documentatie en broncode

- [Technische documentatie](https://docs.mijnoverheidzakelijk.nl) - Uitgebreide technische documentatie over de architectuur en API's
- [GitHub](https://github.com/topics/mijnoverheidzakelijk) - Alle openbare repositories van MijnOverheid Zakelijk

## Berichten/FBS

## Een Proof of Concept (PoC) van het federatieve berichtenstelsel
We werken aan een stelsel waarmee je berichten uit de berichtenmagazijnen van organisaties kan ophalen. In het federatieve stelsel werken overheidsorganisaties, centrale diensten en burgers en ondernemers samen via gestandaardiseerde koppelingen. Iedereen heeft een duidelijke rol:
- Verzenders: overheidsorganisaties die berichten versturen naar ondernemers of burgers.
- Stelsel: de centrale laag die verzenders en ontvangers met elkaar verbindt; zonder dat berichten centraal worden opgeslagen.​
- Ontvangers: ondernemers en burgers die berichten ontvangen en lezen via één centrale interface.

***"Er is géén centrale plek waar alle berichten worden opgeslagen. Elke (overheids)organisatie beheert zijn eigen berichten; het federatieve stelsel zorgt ervoor dat de burger of ondernemer ze altijd op de plek die op dat moment logisch is kan vinden".***

## Waarom is dit nodig?
Overheidsorganisaties communiceren nu elk op hun eigen manier met burgers en ondernemers. Dit leidt tot versnippering: berichten komen via verschillende kanalen binnen, zijn moeilijk terug te vinden en bieden geen eenduidig overzicht. Het Berichten/FBS lost dit op voor alle betrokken partijen:

* Burgers en ondernemers: de berichten kunnen uit de berichtenmagazijnen van organisaties opgehaald worden, op de plek daar waar het logisch is (een MijnOmgeving van de organisaties zijn, maar ook bijv. op het portaal MijnOverheid (Zakelijk), of de bedrijfssoftware van een onderneming, een eigen mobile app, etc.
* Overheidsorganisaties: versturen berichten vanuit het eigen berichtenmagazijn, of versturen berichten via een berichtenmagazijn dat door Logius wordt gehost (specifiek voor die organisatie).
* Digitale overheid: een herbruikbaar stelselcomponent binnen de Generieke Digitale Infrastructuur, gebouwd op open standaarden

## Hoe werkt het federatieve stelsel? Het verhaal van een beschikking van de Belastingdienst aan de ondernemer

```mermaid
---
title: Klantreis ondernemer
---
flowchart LR
  accTitle: Gebruikersreis ondernemer
  accDescr: De ondernemer ontvangt een notificatie over een beschikking, logt vervolgens in met DigiD, eHerkenning of eIDAS, en leest tot slot de beschikking in zijn Berichtenbox.
  A@{ icon: "tabler:bell", label: "Ontvangt notificatie over beschikking" }
  B@{ icon: "tabler:eye", label: "Logt in met DigiD, eHerkenning of eIDAS" }
  C@{ icon: "tabler:file-check", label: "Leest beschikking in zijn Berichtenbox" }
  A --> B --> C
```

```mermaid
---
title: Berichtenstroom Federatief Berichtenstelsel
---
flowchart LR
  accTitle: Berichtenstroom Federatief Berichtenstelsel
  accDescr: De Belastingdienst verstuurt een beschikking naar het Berichtenmagazijn. Het Berichtenmagazijn verstuurt een notificatie en wisselt gegevens uit met het Berichten Uitvraag Systeem. Het Berichten Uitvraag Systeem communiceert met het MOZa portaal, waar de ondernemer het bericht bekijkt.
  BD@{ icon: "tabler:building-bank", label: "Belastingdienst verstuurt beschikking" }
  O@{ icon: "tabler:user", label: "Ondernemer gaat bericht bekijken" }
  MOZa@{ icon: "tabler:device-laptop", label: "MOZa portaal" }
  subgraph FBS["Federatief Berichtenstelsel"]
    direction LR
    BM[(Berichtenmagazijn)]
    BUS[(Berichten Uitvraag Systeem)]
  end
  N@{ icon: "tabler:bell", label: "Verstuurt notificatie" }
  BD --> BM
  O --> MOZa
  BM <--> BUS
  BUS <--> MOZa
  BM --> N
```

## De PoC in meer details
Binnen het [MOZa PoC Federatief Berichtenstelsel](https://minbzk.github.io/moza-poc-fbs-berichtenbox/master/) zijn de volgende onderdelen in scope:
1. Aanlever API: waarmee instanties berichten aanmelden nadat zij die in hun eigen magazijn hebben geplaatst en versturen naar de burger of ondernemer
2. Validatie: elk bericht wordt gecontroleerd op technische eisen en toestemming van de ontvanger.​
3. Publiceren (Publicatie Stream): op de publicatiedatum meldt het berichtenmagazijn het bericht aan bij het Berichten Uitvraag Systeem (BUS).​
4. Ophaal- en Beheer API (vanuit BUS): waarmee berichten worden opgehaald en beheerd vanuit het perspectief van de ontvanger, zodat de burger of ondernemer deze kan lezen daar waar het logisch is (na ingelogd te zijn)
5. UI: een eenvoudige interface die laat zien hoe het stelsel er voor de gebruiker uitziet​​​.
6. Demo omgeving: een testomgeving voor het simuleren van verschillende situaties (nieuw bericht tonen tijdens inlog sessie van de ondernemer, uitvallende berichtenmagazijnen, te traag berichten ophalen, etc)
  
We verwachten na de zomer deze PoC afgerond te hebben. Het stelsel is gebouwd op open standaarden en open source principes: [MinBZK/moza-poc-fbs-berichtenbox: PoC voor de berichtenbox van het Federatief Berichtenstelsel](https://github.com/MinBZK/moza-poc-fbs-berichtenbox/)
Als vervolgstap willen we kleine pilots gaan starten zodat we de stelselafspraken in de praktijk kunnen gaan testen. 

## Doe mee en help ons met openstaande vraagstukken
Wil je als overheidsorganisatie aansluiten op het federatieve stelsel met een pilot, of bijdragen aan de doorontwikkeling hiervan? We werken samen op het gebied van beleid, design, juridische kaders en techniek.

Vraagstukken die open staan en waar we jouw input bij kunnen gebruiken:

- Hoe zorgen we ervoor dat berichten enkel worden getoond aan de personen die ook gemachtigd zijn om de berichten in te zien?
- Wat is er anders qua interactie tussen het berichtenmagazijn van de eigen organisatie versus het gemeenschappelijk berichtenmagazijn?
- Is een aparte 'Berichten' invalshoek wel de toekomst, aangezien berichten (en notificaties) vaak gekoppeld zijn aan een 'zaak'?

## Digitale Assistent

## De Digitale Assistent als Proof of Concept

In de periode januari tot en met april 2026 is een proof of concept (POC) ontwikkeld waarin is onderzocht hoe het Model Context Protocol (MCP) AI-hosts, zoals vlam-chat of in de toekomst wellicht GPT-NL, verbindt met machine-uitvoerbare wetgeving via RegelRecht. [RegelRecht](https://regelrecht.rijks.app/) maakt wetgeving uitvoerbaar als code en bijbehorende uitrekenmachine zodat de wet uitgerekend kan worden. MCP is het protocol waarmee AI-systemen deze machines/engines aanroepen, zodat ondernemers via AI-interactie regels toepassen op de eigen situatie om zaken te doen met de overheid. Om de ondernemer een uniforme ervaring te kunnen bieden, is het van belang dat zowel de uitvoering als de informatievoorziening op dezelfde bron is gebaseerd.

**"De ondernemer stelt een vraag in gewone taal, de assistent kiest zelf welke bron nodig is en laat bij elk antwoord zien waar het vandaan komt".**

> De POC werkt op dit moment voor één casus: de informatieplicht energiebesparing. De KVK draait op de testomgeving, RVO is gesimuleerd en de assistent is nog niet aangesloten op een productieomgeving. Opschalen naar meer wetten en meer uitvoeringsorganisaties is de volgende stap.

## Wat kan de ondernemer (in deze POC)?

De vraag "moet mijn bedrijf voldoen aan de informatieplicht energiebesparing?" wordt in één flow direct afgehandeld. De Digitale Assistent haalt eerst de bedrijfsgegevens op bij de KVK. Vervolgens controleert De Digitale Assistent via RegelRecht of de regel op deze onderneming van toepassing is en of er nog data ontbreekt. De Digitale Assistent verwijst naar het juiste artikel en biedt de ondernemer aan om de rapportage direct bij RVO in te dienen. Eén vraag, één userflow, in plaats van vier websites. Uiteraard in een afgebakende omgeving met de juiste richtlijnen. Van informatievoorziening kan de ondernemer direct overgaan tot het uitvoeren van de actie.

```mermaid
---
title: Digitale Assistent begeleidt de hele klantreis
---
graph LR
  accTitle: Digitale Assistent begeleidt de hele klantreis
  accDescr: De Digitale Assistent begeleidt de ondernemer door de hele klantreis. De ondernemer stelt een vraag in natuurlijke taal, de assistent raadpleegt de KVK en RegelRecht, geeft inzicht in wat geldt voor de situatie, en biedt twee uitkomsten, een verwijzing naar het juiste artikel om zich te informeren, of, na bevestiging, het indienen van de rapportage bij RVO.
  A@{ icon: "tabler:message-question", label: "Vraag in natuurlijke taal" }
  M@{ icon: "tabler:search", label: "Raadpleegt KVK en RegelRecht" }
  G@{ icon: "tabler:bulb", label: "Inzicht: wat geldt voor jouw situatie" }
  D@{ icon: "tabler:book", label: "Verwijzing naar artikel" }
  E@{ icon: "tabler:send", label: "Indienen bij RVO" }

  A --> M --> G
  G -->|informeren| D
  G -->|handelen, na bevestiging| E

  classDef bron fill:#d9ebf7,stroke:#154273,color:#0f172a;
  classDef inzicht fill:#fff8e6,stroke:#b7791f,color:#0f172a;
  class M,E bron
  class G inzicht
```

Bij demonstraties van de Digitale Assistent komen steeds dezelfde vragen terug. Welk probleem lost dit op? Waarom zetten we generatieve AI in? Waarom gebruiken we RegelRecht? En waarom deze technische opzet? Hieronder beantwoorden we die vragen, inclusief de nadelen.

## Welk probleem lost dit op?

Een ondernemer die wil weten of een verplichting voor zijn bedrijf geldt, zoekt dat nu zelf uit. Welke regel geldt, welke organisatie gaat erover, welke gegevens zijn nodig en welk formulier hoort erbij? Die stappen zijn verdeeld over verschillende websites en organisaties, terwijl het voor de ondernemer één vraag is. Dit resulteert in regeldruk. Om diensten te verlenen, daar waar het voor de ondernemer logisch is, brengt de Digitale Assistent die stappen samen in één gesprek, van de vraag tot het indienen van de rapportage. Daarmee bereiken we:

* **Voor ondernemers:** één vraag in gewone taal, in plaats van zelf uitzoeken welke regel geldt en welke organisatie erover gaat. De uitleg gaat over de eigen situatie en de ondernemer kan direct overgaan tot handelen.
* **Voor overheidsorganisaties:** de informatievoorziening en de uitvoering rekenen met dezelfde regel. Wat de assistent zegt, is wat elders ook wordt uitgerekend en wat een formulier of medewerker zou moeten antwoorden.
* **Voor de digitale overheid:** een modulaire, open source opzet waarin elke bron een losse aansluiting is. Een organisatie die haar eigen regelhulp, register of regeling wil koppelen, hoeft de assistent niet opnieuw te bouwen, alleen de eigen bron toe te voegen met de bijbehorende interactie-instructies. Dat past bij de gedachte van MOZa: gezamenlijke services in plaats van ieder zijn eigen portaal.

Bij elk antwoord leggen we de herkomst vast: welke bron is geraadpleegd, welk artikel van toepassing is, op welk moment en met welke gegevens. De ondernemer leest daarmee na waar het antwoord op steunt, en wij verantwoorden achteraf hoe de uitkomst tot stand kwam. Bij een wijziging in de regelgeving wordt die op één plek doorgevoerd en werkt die door in de hele keten.

## Waarom zetten we generatieve AI in?

De overheid heeft al hulpmiddelen die een ondernemer door een regeling heen leiden: regelhulpen, wizards en beslisbomen. Die werken goed voor één regeling, maar ze moeten per regeling gebouwd en onderhouden worden. Bovendien moet de ondernemer weten dát de regeling bestaat, waar de hulp staat en welke vraag hij moet stellen.

Generatieve AI lost een ander deel van het probleem op. Een taalmodel begrijpt een vraag in gewone taal, zoals die aan een adviseur gesteld zou worden. Daarmee vindt het de juiste bronnen bij een vraag, ook als de ondernemer de naam van de regeling niet kent en niet weet welke organisatie erover gaat. Daarnaast combineert het meerdere bronnen in één gesprek: eerst de bedrijfsgegevens bij de KVK, dan de toets bij RegelRecht, dan het indienen bij RVO.

Generatieve AI doet in deze opzet dus twee dingen: de vraag begrijpen en de bronnen in de juiste volgorde aanroepen. Het rekenwerk, het besluit en de gegevens komen ergens anders vandaan.

Die vorm heeft duidelijke voordelen, en net zo duidelijke nadelen:

* **Voordelen:** de ondernemer krijgt uitleg over de eigen situatie en kan doorvragen. Het blijft bovendien niet bij informeren: de assistent vult het formulier alvast in met de gegevens die al bekend zijn en dient het na bevestiging in bij RVO.
* **Nadelen:** een taalmodel beantwoordt dezelfde vraag elke keer net iets anders, en klinkt overtuigend genoeg om niet gecontroleerd te worden. Ook als het rekenwerk aan een tool wordt overgelaten, blijft de eerste stap bij het model: het moet beslissen welke wet van toepassing is en welke inputwaarden daarvoor nodig zijn. Een foutieve keuze levert een berekening op die klopt, maar de verkeerde vraag beantwoordt. Daarnaast moet nog blijken of de trace van een gesprek evenveel gewicht in de schaal legt als een ingevuld formulier. En niet elke ondernemer wil chatten.

Die nadelen bepalen de opzet. Bij elk antwoord toont de assistent de bron en het artikel, handelen gebeurt pas na een expliciete bevestiging en de assistent werkt in een afgebakende omgeving met vaste bronnen en instructies. En het taalmodel rekent niet.

### We willen niet nog een chatvenster erbij

In de POC voeren we het gesprek in een chatvenster, maar dat is de vorm van nu en niet het eindbeeld. Los van de bestaande kanalen lost een chatvenster weinig op: er komt een kanaal bij, terwijl er juist stappen moeten verdwijnen. Zet elke organisatie er zelf een neer, dan ontstaat er versnippering.

We werken daarom toe naar assistentie die in de dienstverlening zelf zit. In het prototype proberen we dat uit met een notificatie, een formulier in het gesprek en een zaakdossier dat ontstaat zodra de rapportage is ingediend. Omdat de bronnen via MCP zijn ontsloten, kan die hulp net zo goed landen in het portaal, in een bestaande regelhulp of in de bedrijfssoftware die de ondernemer al gebruikt. Welke vorm past, is een ontwerpvraag die we samen met ondernemers beantwoorden.

## Waarom gebruiken we RegelRecht?

[RegelRecht](https://regelrecht.rijks.app/) maakt wetgeving uitvoerbaar als code, met een bijbehorende uitrekenmachine. Daarmee ondervangen we het grootste risico van generatieve AI bij de overheid: het taalmodel interpreteert de wet niet. Het taalmodel begrijpt de vraag van de ondernemer en voert het gesprek, de uitkomst komt van RegelRecht. Generatieve AI bepaalt dus niet of een ondernemer aan een verplichting moet voldoen, maar de regel zelf.

```mermaid
---
title: Rolverdeling tussen taalmodel en RegelRecht
---
graph LR
  accTitle: Rolverdeling tussen taalmodel en RegelRecht
  accDescr: De ondernemer stelt een vraag. Het taalmodel voert het gesprek en vertaalt de vraag naar een toets. RegelRecht rekent de regel uit en bepaalt de uitkomst. De ondernemer krijgt een antwoord met de bron en het wetsartikel erbij.
  V@{ icon: "tabler:message-question", label: "Vraag van de ondernemer" }
  T@{ icon: "tabler:robot", label: "Taalmodel voert het gesprek" }
  R@{ icon: "tabler:calculator", label: "RegelRecht rekent de regel uit" }
  A@{ icon: "tabler:file-check", label: "Antwoord met bron en artikel" }

  V --> T --> R --> A

  classDef bron fill:#d9ebf7,stroke:#154273,color:#0f172a;
  classDef inzicht fill:#fff8e6,stroke:#b7791f,color:#0f172a;
  class R bron
  class A inzicht
```

Deze opzet levert vier dingen op:

* **Een herhaalbare uitkomst:** een taalmodel geeft op dezelfde vraag soms een net iets ander antwoord, een berekening niet. Dezelfde gegevens leiden altijd tot dezelfde uitkomst, en die uitkomst is te controleren.
* **Eén plek voor wijzigingen:** verandert de wet, dan passen we de regel op één plek aan. Alle kanalen die RegelRecht gebruiken, rekenen daarna met de nieuwe regel.
* **Een uitlegbaar antwoord:** RegelRecht geeft de wettelijke grondslag herleidbaar terug, zodat de assistent verwijst naar het artikel waar de uitkomst op steunt.
* **Hergebruik in plaats van zelf bouwen:** RegelRecht bestaat al en heeft een eigen team. We sluiten aan en werken samen, in plaats van een eigen regelmotor te bouwen naast wat er al is.

Dat de uitkomst uit een berekening komt, betekent niet dat die klopt. Een wet moet eerst worden omgezet naar een machine-uitvoerbare wet, en die omzetting moet gevalideerd worden. Daarom is validatie een van onze [vervolgstappen](#hoe-gaan-we-nu-verder).

## Waarom deze technische opzet?

De assistent bestaat uit drie lagen die los van elkaar te vervangen zijn: een AI-host waarin het gesprek plaatsvindt (nu vlam-chat, in de toekomst wellicht GPT-NL), het [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) als koppelvlak, en de bronnen van de organisaties zelf.

```mermaid
---
title: Raadpleging bronnen en tools door Digitale Assistent
---
graph LR
  accTitle: Raadpleging bronnen en tools door Digitale Assistent
  accDescr: De ondernemer stelt een vraag aan de Digitale Assistent. Die raadpleegt via het MCP-protocol drie bronnen. KVK levert bedrijfsgegevens. RegelRecht toetst de regel en geeft de wettelijke grondslag terug. RVO is de bron waar de rapportage na bevestiging wordt ingediend.
  O@{ icon: "tabler:user", label: "Ondernemer" }
  D@{ icon: "tabler:robot", label: "Digitale Assistent" }
  K@{ icon: "tabler:building", label: "KVK" }
  R@{ icon: "tabler:scale", label: "RegelRecht" }
  V@{ icon: "tabler:send", label: "RVO" }

  O <--> D
  D -->|ophalen| K
  D -->|toetsen| R
  D -->|indienen| V

  classDef bron fill:#d9ebf7,stroke:#154273,color:#0f172a;
  class K,R,V bron
```

Die knip is een bewuste keuze:

* **De bron blijft bij de eigenaar.** De KVK levert de bedrijfsgegevens, RegelRecht toetst de regel en RVO ontvangt de rapportage. Er ontstaat geen centrale kopie van gegevens en geen nieuwe partij die namens anderen antwoord geeft. Dezelfde federatieve gedachte als bij [Berichten/FBS](/onderwerpen/berichten-fbs/index.md).
* **Eén koppelvlak in plaats van een koppeling per assistent.** Een organisatie sluit haar bron één keer aan via MCP en die aansluiting is daarna bruikbaar voor elke AI-host. Daarom werken we ook mee aan een MCP-standaard voor de overheid.
* **Geen eigen assistent per organisatie.** Een assistent per organisatie levert dezelfde versnippering op als een portaal per organisatie: de ondernemer moet dan opnieuw uitzoeken bij wie hij moet zijn.
* **Vervangbare onderdelen.** Het taalmodel bevat zelf geen kennis van wetten of bedrijfsgegevens. Een ander model of een andere host inzetten is daarmee een wissel en geen verbouwing.

## Hoe gaan we nu verder?

**Validatie**

De POC werkt met wetten die zijn omgezet naar RegelRecht. De vraag die de demo's van de POC hebben opgeleverd is of die omzetting inhoudelijk klopt: *weerspiegelen de machine-uitvoerbare wetten daadwerkelijk wat de wet bedoelt en hoe uitvoeringsorganisaties die in de praktijk toepassen?* Zonder deze validatie is de betrouwbaarheid van de gehele keten onzeker. Als de machine-uitvoerbare wetten niet kloppen, kloppen de antwoorden aan de ondernemer ook niet. Dit raakt direct aan het vertrouwen in de standaard en aan de bruikbaarheid voor eventuele opschaling.

**Ondernemer centraal**

Daarnaast heeft de POC zich overwegend op de technische werking gefocust, maar of de interactie ook klopt vanuit het perspectief van de ondernemer is nog niet onderzocht. Daarom willen we in de aankomende periode een representatieve user flow uitwerken en toetsen met een kleine groep ondernemers: begrijpen zij wat er gebeurt, vertrouwen zij de uitkomst, en weten zij wat zij ermee moeten doen? Want we moeten ondernemers helpen en we weten nu niet zeker hoe de integratie van deze technologie daar het beste aan bijdraagt. Gebruikersonderzoek voorkomt dat aannames over gebruikersbegrip en vertrouwen ongetoetst blijven tot het te laat is om bij te sturen.

## Doe mee en help ons met openstaande vraagstukken

Wil je als overheidsorganisatie aansluiten op de Digitale Assistent, of bijdragen aan de doorontwikkeling van RegelRecht en de Digitale Assistent? We werken samen op het gebied van beleid, design, juridische kaders en techniek.

Dit zijn nog openstaande punten:

* Hoe zorgen we dat RegelRecht niet alleen een bron van documenten is met bijbehorende uitrekenmachine voor de Digitale Assistent, maar ook de standaard uitvoering voert?
* Welke vorm past bij de ondernemer: een gesprek, hulp binnen het portaal, of een aansluiting op de software die de ondernemer al gebruikt?
* Wie is verantwoordelijk als de assistent een fout antwoord geeft, en hoe leggen we dat vast met de uitvoeringsorganisaties?
* Welke eisen stellen we aan het taalmodel zelf, bijvoorbeeld op het gebied van privacy, leveranciersafhankelijkheid en energieverbruik?

Heb je hier feedback op, of wil je ergens over meedenken? Dat kan altijd.

## Meer info

- [RegelRecht](https://regelrecht.rijks.app/)

- [Van MCP naar CLI?](https://github.com/MinBZK/moza-poc/blob/feat/add_digitale_assistent/services/decisions/PDR-005-cli-vs-mcp-transport.md)

## Actualiteitenservice

## Huidige uitdaging

Ondernemers krijgen overheidsinformatie op allerlei manieren en van verschillende kanten. Omdat er geen centrale plek is waar alles samenkomt, moeten ze zelf overal zoeken, inloggen en filteren. Daardoor missen ze soms belangrijke berichten, lopen ze subsidies mis of voldoen ze per ongeluk niet aan verplichtingen.

## Wat is de actualiteitenservice?

De actualiteitenservice laat ondernemers de informatie zien die voor hen relevant is. Die informatie komt uit verschillende overheidsbronnen. Denk aan nieuwe wetten, subsidies of lokale ontwikkelingen.

De service filtert die informatie op kenmerken als branche, locatie of bedrijfsgrootte. Waar het kan vullen we die kenmerken vooraf in, maar ondernemers passen ze altijd zelf aan. Wie dat wil, krijgt daarnaast automatisch een signaal bij nieuwe ontwikkelingen.

## De oplossing

Hieronder lichten we de belangrijkste uitgangspunten van de actualiteitenservice toe. We beschrijven ook hoe de service werkt voor ondernemers en voor overheidsorganisaties.

### Gegevens

De actualiteitenservice werkt met **informatie-berichten** en **filterkenmerken**. In de ideale opzet koppelt een dienstverlener elk informatie-bericht aan een of meer filterkenmerken. Zo komt een bericht alleen terecht bij de ondernemers voor wie het relevant is, in een inbox die daar speciaal voor bedoeld is.

* **Informatie-bericht**: de informatie die een overheidsorganisatie wil delen, zoals een nieuwe wet, subsidie of lokale ontwikkeling.

* **Filterkenmerken**: de kenmerken waarop de informatie gefilterd wordt, zoals branche, locatie, bedrijfsgrootte, onderwerp of urgentie.

### Informatie

Elk informatie-bericht wordt gekoppeld aan een of meerdere **filterkenmerken**. Deze kenmerken bepalen welke ondernemers het informatie-bericht te zien krijgen. Een informatie-bericht kan bijvoorbeeld gekoppeld zijn aan de branche *Horeca* en de locatie *Amsterdam*, zodat alleen horecaondernemers in Amsterdam het informatie-bericht ontvangen.

De actualiteitenservice toont daarmee alleen informatie-berichten die relevant zijn voor ondernemers en die hen helpen hun bedrijfsprocessen beter uit te voeren. Concreet gaat het om informatie zoals wet- en regelgeving, subsidies, lokale ontwikkelingen en urgente mededelingen.

### Hergebruik gegevens

Een informatie-bericht kan relevant zijn voor meerdere ondernemers. Daarom wordt elk informatie-bericht opgeslagen met de bijbehorende filterkenmerken, zodat het automatisch getoond kan worden aan alle relevante ondernemers. Dit zorgt voor efficiëntie en voorkomt dat dezelfde informatie meerdere keren gepubliceerd moet worden.

### Hoe werkt dit voor ondernemers?

```mermaid
---
title: Klantreis ondernemer
---
graph LR
  accTitle: Klantreis ondernemer
  accDescr: De stappen die een ondernemer doorloopt: inloggen met eHerkenning of eIDAS, profiel instellen, informatie-berichten bekijken.
  A@{ icon: "tabler:login", label: "Inloggen met eHerkenning of eIDAS" }
  B@{ icon: "tabler:user", label: "Profiel instellen" }
  C@{ icon: "tabler:news", label: "Informatie-berichten bekijken" }
  D@{ icon: "tabler:bell", label: "Proactieve signalen ontvangen" }
  A --> B --> C --> D

```
Je logt in met eHerkenning of een Europees inlogmiddel (eIDAS), stelt je actualiteitenprofiel in met de relevante filterkenmerken en bekijkt de informatie-berichten die voor jou relevant zijn. Daarnaast ontvang je proactieve signalen over nieuwe ontwikkelingen.

### Filterkenmerken

De service filtert informatie op basis van bedrijfsspecifieke kenmerken. Hieronder een *illustratief* overzicht van de kenmerken waarop gefilterd kan worden:

| **Categorie**       | **Voorbeelden**                                                            | **Toelichting**                                           |
| ------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------- |
| **Branche**         | Horeca, Bouw, Zorg, Retail, Landbouw, IT, Transport                        | Bepaalt welke sector-specifieke informatie getoond wordt. |
| **Locatie**         | Gemeente, Provincie, Landelijk, EU-wijd                                    | Filtert op regionale regelgeving en subsidies.            |
| **Bedrijfsgrootte** | ZZP, MKB (1-50), Middelgroot (50-250), Groot (250+)                        | Bepaalt welke regelgeving van toepassing is.              |
| **Onderwerpen**     | Subsidies, Wetgeving, Ruimtelijke ordening, Milieu, Financieel, Veiligheid | Stel in welke onderwerpen je wilt volgen.                 |
| **Urgentie**        | Laag, Medium, Hoog, Kritiek                                                | Filter op belangrijkheid van informatie-berichten.        |

### Proactieve signalen

```mermaid
---
title: Proactieve signalen
---
graph LR
  accTitle: Proactieve signalen
  accDescr: Het proces van proactieve signalen: informatie-bericht publiceren, filtering toepassen, signaal versturen.
  A@{ icon: "tabler:edit", label: "Dienstverlener publiceert informatie-bericht" }
  B@{ icon: "tabler:filter", label: "Filtering toepassen" }
  C@{ icon: "tabler:bell", label: "Signaal versturen" }
  D@{ icon: "tabler:user", label: "Ondernemer ontvangt signaal" }
  A --> B --> C --> D
```

Wanneer een nieuw informatie-bericht wordt gepubliceerd door een dienstverlener, past de actualiteitenservice filterkenmerken toe en verstuurt indien gewenst een signaal over deze informatie naar de relevante ondernemers. Gekoppeld aan de notificatiedienst kan de ondernemer een signaal via het gekozen kanaal, zoals e-mail of een melding in hun dashboard, ontvangen.

## Hoe werkt dit voor overheidsorganisaties?

Hieronder lees je hoe dit kan werken voor een overheidsorganisatie. Let op: in de proefopstelling die we gebouwd hebben, passen we nog niet al deze principes toe. Er zijn ook meerdere manieren om dit vorm te geven. Wat je hieronder ziet, is dus één van de mogelijke uitwerkingen.

### Publicatieproces

In dit geval publiceert een overheidsorganisatie informatie-berichten via de actualiteitenservice. De informatie-berichten worden automatisch gefilterd en getoond aan de relevante ondernemers.

```mermaid
---
title: Publicatieproces overheidsorganisatie
---
graph LR
  accTitle: Publicatieproces overheidsorganisatie
  accDescr: De stappen die een overheidsorganisatie doorloopt: aansluiten via FSC/FTV, informatie-berichten publiceren, automatische distributie.
  A@{ icon: "tabler:plug-connected", label: "Aansluiten via FSC/FTV" }
  B@{ icon: "tabler:edit", label: "Informatie-berichten publiceren" }
  C@{ icon: "tabler:share", label: "Automatische distributie" }
  A --> B --> C
```

Overheidsorganisaties sluiten eenmalig aan via Federatieve Service Connectiviteit (FSC) en Federatieve Toegangsverlening (FTV). Daarna publiceren zij hun informatie-berichten. Bij elk bericht geven ze de filterkenmerken mee in een vast formaat, zodat de service ze automatisch kan verwerken. De actualiteitenservice zorgt vervolgens voor de distributie naar de relevante ondernemers.

### Filterkenmerken

Elk informatie-bericht moet voorzien zijn van gestructureerde filterkenmerken voor optimale filtering. Hieronder een voorbeeld van verschillende kenmerken.

| **Filterkenmerk**   | **Voorbeeldwaarden**                      | **Verplicht?** | **Toelichting**                                       |
| ------------------- | ----------------------------------------- | -------------- | ----------------------------------------------------- |
| **Doelgroep**       | Horeca, Bouw, Zorg, MKB, Grote bedrijven  | Ja             | Bepaalt welke ondernemers het informatie-bericht zien. |
| **Regio**           | Landelijk, Noord-Holland, Amsterdam       | Ja             | Voor lokale of regionale informatie-berichten.         |
| **Onderwerp**       | Subsidie, Wetgeving, Ruimtelijke ordening | Ja             | Categorie van het informatie-bericht.                  |
| **Urgentie**        | Laag, Medium, Hoog, Kritiek               | Ja             | Bepaalt de prioriteit in de weergave.                  |
| **Geldigheid**      | Tijdelijk (datum), Permanent              | Nee            | Voor tijdgebonden informatie-berichten.                |
| **Contactgegevens** | E-mail, telefoonnummer, website           | Nee            | Voor vervolgvragen.                                    |

## Huidige status

We hebben de actualiteitenservice als concept getest bij gebruikers. Ook bouwden we een eerste testversie (een vroege alfaversie). Zo konden we nagaan of de ideeën technisch haalbaar zijn.

### Functioneel

In deze eerste testversie kan de actualiteitenservice het volgende:

1. Een ondernemer kan via een portaal zijn profiel instellen met de relevante filterkenmerken.

2. Informatie-berichten van overheidsorganisaties kunnen (automatisch) gefilterd worden (op basis van eerder ingegeven voorkeuren) en getoond worden aan de ondernemers.

### Technisch

Om die functies te bieden hebben we technisch het volgende ingeregeld:

* Centraal ophalen van informatie uit verschillende bronnen:

  * [de API van Ondernemersplein](https://ondernemersplein.overheid.nl/ondernemersplein-api/)

  * [wetten.overheid.nl](https://wetten.overheid.nl/)

  * [Berichten over uw buurt](https://www.overheid.nl/berichten-over-uw-buurt)

* Koppelen van informatie-berichten aan filterkenmerken

* Mogelijkheid tot het instellen van verschillende filterkenmerken, waaronder branche, locatie, bedrijfsgrootte, onderwerp en urgentie.

## Vervolgstappen

Uit [gebruikersonderzoek](/weekly/moza-weekly-20-mei-2026/#gebruikersonderzoek) blijkt dat de service ondernemers op dit moment te weinig oplevert. Ondernemers willen vooral informatie zien die echt over hun eigen situatie gaat. Dat kunnen we nu nog niet bieden.

Daar zijn twee redenen voor. De informatie uit de bronnen heeft nog niet de filterkenmerken die we voor dat filteren nodig hebben. En in de huidige vorm voegt die informatie te weinig toe voor ondernemers.

Daarom pauzeren we de verdere ontwikkeling van de actualiteitenservice.

## Meedoen

We hebben de actualiteitenservice gebouwd om ondernemers te helpen. Daarvoor hebben we nu nog niet de juiste bronnen. En de service heeft alleen waarde als meerdere overheidsorganisaties meedoen.

Heb je nieuwe inzichten op dit gebied? Neem dan contact met ons op. We nodigen je uit om mee te denken, mee te bouwen en kennis te delen: [praat met ons mee!](/contact/index.md)

## Meer info

* [Voortgang en broncode op GitHub](https://github.com/MinBZK/moza-actualiteiten-service)

* Uitproberen in [het portaal MijnOverheid Zakelijk](https://moza.mijnoverheidzakelijk.nl/) als onderdeel van [de proeftuin](/onderwerpen/proeftuin/index.md)

# Handboek

Interne documentatie voor het MOZa team.

## Bijdragen aan handboek

Dit handboek is er voor het hele team. Iedereen kan bijdragen door content aan te passen, pagina's toe te voegen of verbeteringen voor te stellen.

## Waarom bijdragen

Door bij te dragen aan het handboek help je:
- Het handboek actueel en correct te houden
- Nieuwe teamleden sneller op weg te helpen
- Kennis te delen met het hele team
- De documentatie te verbeteren

## Hoe bij te dragen

Het handboek staat in de [Git repository op GitHub](https://github.com/minbzk/moza-site). Je kunt wijzigingen voorstellen via een [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests).

### Suggestie indienen zonder code

Je kunt een [issue aanmaken](https://github.com/minbzk/moza-site/issues/new) met je suggestie, dan zal iemand anders het oppakken.

### Eenvoudig: direct editen op GitHub

De snelste manier om een wijziging door te voeren:

1. **Ga naar de pagina** - Navigeer naar het bestand op [GitHub](https://github.com/minbzk/moza-site/tree/main/content/handboek)
2. **Klik op het potlood** - Rechtsboven zie je een potlood-icoon om te editen
3. **Bewerk de tekst** - Pas de markdown aan
4. **Commit wijziging** - Vul een beschrijving in en klik op "Propose changes"
5. **Maak pull request** - GitHub maakt automatisch een pull request aan

### Gevorderd: via lokale clone

Voor grotere wijzigingen of als je lokaal wilt testen:

1. **Clone de repository** - Haal de code op naar je lokale machine
2. **Maak een branch** - Maak een nieuwe branch voor je wijziging
3. **Bewerk de content** - Pas markdown bestanden aan in `content/handboek/`
4. **Test lokaal** - Draai `just up` om je wijziging te zien
5. **Commit je wijziging** - Leg je wijziging vast met een duidelijke commit message
6. **Push naar GitHub** - Upload je branch naar GitHub
7. **Maak een pull request** - Vraag je wijziging te reviewen

## Schrijfrichtlijnen

### Taal en stijl

- **Nederlands** - Alle content is in het Nederlands
- **B1-niveau** - Houd de taal eenvoudig en toegankelijk
- **Korte zinnen** - Max 15-20 woorden per zin
- **Actieve zinnen** - "We doen" in plaats van "wordt gedaan"
- **Informeel maar respectvol** - Spreek de lezer aan met "je"

### Structuur

- **Duidelijke koppen** - Gebruik H2 (##) en H3 (###) voor structuur
- **Korte alinea's** - Max 3-4 zinnen per alinea
- **Opsommingen** - Gebruik lists voor overzichten
- **Links** - Verwijs naar relevante bronnen

### Front matter

Elke pagina heeft YAML front matter met:
- **title** - De titel van de pagina
- **description** - Korte beschrijving (max 160 tekens)

Voorbeeld:
```yaml
---
title: Mijn pagina
description: Korte beschrijving van deze pagina.
---
```

## Reviews

Alle wijzigingen worden gereviewd voordat ze live gaan. Dit zorgt ervoor dat:

- De content klopt
- De taal en stijl consistent is
- Er geen fouten in zitten
- Links werken

Je kunt ook helpen door pull requests van anderen te reviewen.

## Wat kun je bijdragen

### Correcties

- Tikfouten of taalfouten herstellen
- Verouderde informatie bijwerken
- Dode links vervangen

### Verbeteringen

- Onduidelijke tekst verduidelijken
- Ontbrekende informatie aanvullen
- Voorbeelden toevoegen

### Nieuwe pagina's

- Nieuwe onderwerpen toevoegen
- FAQ's schrijven
- Tutorials of how-to's maken

## Niet zeker of het goed is?

Doe gerust een voorstel door ons een opzet te sturen, of maak een pull request. Ook als je niet zeker bent of het klopt. Dat is waar reviews voor zijn. Liever een imperfecte bijdrage dan helemaal geen bijdrage.

Als je twijfelt, vraag het eerst in [Mattermost](../../jouw-start/accounts-en-tools/#mattermost). We denken graag mee.

## Vragen?

Vragen over hoe je kunt bijdragen aan het handboek? Vraag het in [Mattermost](../../jouw-start/accounts-en-tools/#mattermost) of [zoek contact](/contact/index.md) met ons.

## De eerste dagen

Welkom bij het MOZa team. We werken met MijnOverheid Zakelijk aan een overheid waar ondernemers centraal staan. Elk uur minder aan gedoe is een uur meer ondernemen. Wij zorgen voor overzicht en maken het makkelijk om zaken te doen met de overheid.

## Wat is MOZa

MOZa staat voor MijnOverheid Zakelijk. Ondernemers besteden nu te veel tijd aan overheidszaken. Wij zorgen ervoor dat dit makkelijker wordt. Met MOZa krijgen ondernemers overzicht over hun zaken en kunnen ze direct handelen. Dat scheelt gedoe en geeft meer tijd voor ondernemen.

We zitten nu in Fase 3 van het programma en zijn nu bezig met het realiseren van het MVP: de eerste versie die toegevoegde waarde levert voor ondernemers. In de vorige fases hebben we:
- De visie en uitgangspunten uitgewerkt
- Een eerste demo gebouwd
- Gebruikerstests uitgevoerd

Meer over de geschiedenis en waar we naartoe werken vind je in de sectie [Over MOZa](/over-moza/index.md).

 Neem je tijd
> We beseffen ons dat er veel te lezen is en dat het een uitdagende context is waarin we werken. Neem daar gerust de tijd voor. Je hoeft niet alles na de eerste week te weten.

## Hoe we werken

Bij MOZa werken we zo open mogelijk:

- **Transparant** - Beslissingen leggen we vast en delen we openbaar
- **Open werken** - We delen ons werk via deze site en werken in het openbaar op GitHub, waar iedereen met ons kan samenwerken
- **Samen** - We kunnen dit niet alleen en zoeken daarom actief samenwerking met andere organisaties en zakelijke gebruikers

Elke week versturen we een **[MOZa Weekly](/weekly/)** voor iedereen die volgt wat we doen. Jouw input is essentieel. Deel daarom wekelijks in het [check-in](https://digilab.overheid.nl/chat/mijnoverheid-zakelijk/channels/check-in) kanaal wat je hebt gedaan, geleerd of gemaakt. Het liefst met concrete voorbeelden, zoals linkjes naar demo's, screenshots, repo's, pull requests of andere dingen waar je trots op bent.

## Samenwerkdagen

We hebben twee vaste samenwerkdagen per week:

- **Maandag** - DigiVloer Den Haag (naast NS station Den Haag Laan van NOI)
- **Woensdag** - Dev.loer Utrecht (deze locatie is tijdelijk gesloten, een nieuwe locatie volgt)

Meer informatie over de locaties waar we samenwerken en hoe je een werkplek reserveert, vind je op de pagina [hybride samenwerken](/handboek/jouw-start/hybride-samenwerken/index.md).

## Toegang tot tools

Je hebt toegang nodig tot:

- **Mattermost** - Voor dagelijkse communicatie met het team
- **GitHub** - Voor code, documentatie en planning
- **Samenwerkruimte** - Voor programma-documenten en presentaties

Zie de pagina [accounts en tools](/handboek/jouw-start/accounts-en-tools/index.md) voor uitleg en links.

## Het team leren kennen

In de samenwerkruimte vind je o.a. [het smoelenboek](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers/Gedeelde%20%20documenten/01%20-%20Programmadocumenten/11%20-%20Team/Smoelenboek%20MOZa.pptx?web=1) met foto's en contactgegevens van alle teamleden. Meer over de teamsamenstelling en wie je waarvoor kunt benaderen, vind je op de pagina [het team](/handboek/jouw-start/het-team/index.md).

## Vragen?

Stel gerust vragen in Mattermost of tijdens een samenwerkdag. Iedereen helpt je graag om je wegwijs te maken.

## Principes

Bij MOZa werken we vanuit vaste principes. Deze helpen ons om de juiste keuzes te maken en consistent te werken.

## Ondernemer centraal

Bij MOZa staan ondernemers centraal. Elk uur minder aan gedoe, is een uur meer ondernemen. We zorgen voor overzicht en makkelijk zakendoen met de overheid. Met elkaar bouwen we zo aan nieuwe digitale snelwegen.

Daarom:

- Doen we regelmatig gebruikersonderzoek
- Nodigen we zakelijke gebruikers uit voor testen
- Gebruiken we eenvoudige taal (B1-niveau)
- Zorgen we voor digitale toegankelijkheid (WCAG 2.1 AA)

Meer over voor wie we bouwen vind je op de pagina [Over MOZa](/over-moza/index.md).

## Open werken, tenzij

We werken zo open mogelijk. Dat betekent:

- **Delen van kennis** - We publiceren onze learnings en inzichten
- **Open source** - Onze code is publiek toegankelijk op GitHub
- **Transparante besluitvorming** - We leggen belangrijke beslissingen vast
- **Samenwerking** - We werken samen met andere overheidsteams

Door open te werken kunnen anderen van ons werk leren en kunnen we zelf ook leren van anderen. We publiceren daarbij zoveel mogelijk op onze publieke omgeving:

- [**Deze site**](/) - Informatie over het programma
- [**Proeftuin**](/onderwerpen/proeftuin/index.md) - Experimenteeromgeving waar we ontdekken wat werkt en wat niet
- [**Demo portaal**](https://moza.mijnoverheidzakelijk.nl/) - Werkende demo, maar nog in ontwikkeling
- [**MOZa repositories**](https://github.com/topics/mijnoverheidzakelijk) - Alle broncode

Dit helpt ons om vroeg feedback te krijgen en transparant te zijn over onze voortgang.

Uiteraard kunnen we niet altijd open werken. Sommige informatie is vertrouwelijk en kan niet openbaar worden gemaakt. En om samen te werken zijn ook verkennende gesprekken nodig die in vertrouwelijke omgevingen plaatsvinden. Op het principe open werken zijn dus uitzonderingen mogelijk, maar we proberen wel zoveel mogelijk open te werken.

## NeRDS principes

We werken volgens de **[NeRDS](https://minbzk.github.io/NeRDS/)** (Nederlandse Richtlijn Digitale Systemen) principes. Dit zijn richtlijnen voor digitale overheidsdiensten. Als er iets essentieels ontbreekt in de NeRDS, dragen we daar actief aan bij. We zijn niet alleen gebruikers, maar ook mede-eigenaren van deze standaarden.

### Gebruikersgericht

We bouwen voor en met gebruikers:
- Regelmatig gebruikersonderzoek om behoeften te begrijpen
- Testen van ontwerpen met echte ondernemers en gemachtigden
- Iteratief werken: stap voor stap verbeteren op basis van feedback

### Werk samen

Alleen ga je sneller, samen kom je verder. Daarom zoeken wij actief de samenwerking op. Dat betekent dat we:

- Kennis delen met andere overheidsteams
- Hergebruiken van bewezen oplossingen en componenten stimuleren
- Standaardisatie van ontwerpen en implementaties toepassen, om overheidsorganisaties technisch met elkaar te laten communiceren

We werken samen met communities zoals:

- [**MijnServices**](https://vng.nl/MijnServices) - Voor en door gemeenten (VNG)
- [**GEMMA Omnichannel**](https://www.gemmaonline.nl/wiki/Omnichannel_Ambitie) - Architectuur en standaarden
- [**NL Design System**](https://nldesignsystem.nl/) - Herbruikbare componenten voor overheidsdiensten
- [**IBDS**](https://realisatieibds.nl/) - Interbestuurlijke Datastrategie met o.a. Federatief Datastelsel
- **OBIS** - Overheidsbrede Interactieservices (Logius)
- [**developer.overheid.nl**](https://developer.overheid.nl/) - Centrale plek voor developers

### Toegankelijk

Iedereen moet MOZa kunnen gebruiken:
- WCAG 2.1 niveau AA voor digitale toegankelijkheid
- B1 taalniveau zodat teksten voor iedereen begrijpelijk zijn
- NL Design System componenten die toegankelijkheid borgen

### Veilig en betrouwbaar

We zorgen voor privacy, veiligheid en betrouwbaarheid:

- Federatief stelsel: data blijft bij de bron, organisaties blijven eigenaar
- Vermijding van redundantie: geen onnodig kopiëren van data
- Verantwoord gebruik met transparantie en privacy
- Veilige authenticatie via DigiD en eHerkenning
- Vertrouwen door afspraken en standaarden

### Herbruikbaar

We ontwikkelen generieke diensten die meerdere organisaties kunnen gebruiken, herbruiken en doorontwikkelen. Dit voorkomt dubbel werk en zorgt voor snellere, betere oplossingen.

Wat we bouwen kan door anderen gebruikt worden:

- Generieke diensten die meerdere organisaties kunnen inzetten
- Open source code op GitHub
- Interoperabele systemen die data kunnen uitwisselen

## Iteratief werken

We werken in korte iteraties. We bouwen stap voor stap en leren onderweg. Dit voorkomt dat we te lang bouwen aan iets dat niet goed blijkt te werken.

Elke fase van MOZa heeft geleerd van de vorige fase. We documenteren onze learnings zodat we (en anderen) daarvan kunnen leren.

Meer over hoe we in de praktijk werken vind je in de sectie [Rituelen](../rituelen/).

## Wat is MOZa

MOZa staat voor **MijnOverheid Zakelijk**. Wij bouwen interactieservices waarmee overheidsorganisaties hun digitale dienstverlening aan ondernemers kunnen verbeteren. Denk aan notificaties, berichten, taken en machtigingen. Lees meer over wat we bouwen in de sectie [onderwerpen](/onderwerpen/).

Op de pagina [Over MOZa](/over-moza/index.md) vind je meer achtergrondinformatie bij het programma.

## Wat bouwen we

We ontwikkelen generieke interactieservices die overheidsorganisaties kunnen gebruiken:

- **Berichtenservice**: berichten van de overheid op één plek
- **Profielservice**: contactgegevens en voorkeuren centraal beheren
- **Notificatieservice**: een seintje als een ondernemer iets moet doen
- **Takenlijst**: overzicht van openstaande acties
- **Zakenlijst**: overzicht van zaken die lopen bij de overheid

Deze services zijn federatief: de data blijft bij de bron en kan in verschillende interfaces worden getoond.

Er is een werkende demo van MOZa beschikbaar. In deze demo kun je zien hoe MOZa eruit ziet en hoe het werkt. De demo wordt regelmatig bijgewerkt met nieuwe functionaliteit.

> **Link**: [moza.mijnoverheidzakelijk.nl](https://moza.mijnoverheidzakelijk.nl/)

Daarnaast is er veel meer om uit te proberen. Een overzicht hiervan vind je in [onze proeftuin](/onderwerpen/proeftuin/index.md).

## Onze rituelen

Bij MOZa hebben we een aantal vaste rituelen. Deze helpen ons om op de hoogte te blijven, samen te werken en te reflecteren op ons werk.

## Dagelijks

### Dagelijkse standup (tech team)

Het tech team heeft een dagelijkse standup. Hier bespreken we:

- Wat hebben we gisteren gedaan
- Wat gaan we vandaag doen
- Zijn er blokkades

Dit is een kort overleg (max 15 minuten) om iedereen op de hoogte te houden.

## Wekelijks

### Maandag samenwerken

Op maandag hebben we een samenwerkdag waar we:

- Samen aan projecten werken
- Kennis delen
- Face-to-face overleggen
- Elkaar helpen

### Wekelijkse check-in

Elke week vragen we aan jou om een geschreven update te delen in het [check-in kanaal op Mattermost](https://digilab.overheid.nl/chat/mijnoverheid-zakelijk/channels/check-in). Deel in deze update:

- Wat je deze week hebt gedaan of geleerd
- Wie je hebt ontmoet
- Voorbeelden waar je trots op bent: linkjes naar demo's, screenshots, repo's, pull requests
- Hulp of vragen

### MOZa Weekly

Elke week versturen we een MOZa Weekly voor iedereen die volgt wat we doen. Deze is gebaseerd op wat je deelt in de wekelijkse check-in.

## Tweewekelijks

### Retrospective en refinement

Eens per twee weken hebben we een retrospective en refinement sessie. Dit is een moment om te reflecteren op hoe we samenwerken én om aankomend werk te bespreken.

We gebruiken een [Mattermost board](/handboek/jouw-start/accounts-en-tools/index.md#mattermost) met vier kolommen:

- **Wat gaat goed 👍** - Dingen die goed gaan en die we willen behouden
- **Wat kan er beter 🚫** - Zaken die verbeterd kunnen worden
- **Ideeën 💡** - Suggesties en nieuwe ideeën om uit te proberen
- **Acties ✅** - Concrete acties die we oppakken

Na de retro bespreken we aankomende taken en verduidelijken we requirements waar nodig. Dit helpt ons om goed voorbereid te zijn op het werk dat voor ons ligt.

### Team overleg

Eens per twee weken hebben we een team overleg. Hier bespreken we:

- Grotere ontwikkelingen
- Teamzaken
- Proces en werkwijze
- Stand van zaken huidige fase

## Maandelijks

### Regieteam

Eens per maand komt het regieteam bij elkaar. Dit overleg gaat over:

- Strategische beslissingen
- Prioritering van werk
- Afstemming met stakeholders

### MOZa Pulse

Eens per 4 weken hebben we een MOZa Pulse. Dit is een moment om te laten zien waar we aan werken en te delen wat onze plannen zijn.

## Tweemaandelijks

### Stuurgroep

Eens per twee maanden komt de stuurgroep bij elkaar. Dit overleg gaat over:

- Voortgang van het programma
- Grote beslissingen
- Bespreken strategische keuzes
- Beantwoorden hulpvragen

## Per fase (viermaandelijks)

### Fase reflectie en voorbereiding

Eens per fase (ongeveer elke 4 maanden) nemen we een hele dag de tijd om:

- Te reflecteren op wat we hebben geleerd
- Successen en uitdagingen te bespreken
- Richting en prioriteiten voor de volgende fase te bepalen

Dit is een belangrijk moment om samen stil te staan bij onze voortgang en de volgende stappen te zetten.

## Governance

Het MOZa programma kent een governance-model met vier groepen die samenwerken rondom de te ontwikkelen dienstverlening. Dit model zorgt ervoor dat beslissingen genomen worden door de juiste mensen en dat iedereen weet waar verantwoordelijkheden liggen.

Het model is zo ingericht dat teams autonoom kunnen werken. De stuurgroep hoeft niet voor elke stap een akkoord te geven. Het opdrachtgeverschap ligt bij de directie [Digitale Overheid (PDI)](https://organisaties.overheid.nl/27646725/Directie_Digitale_Overheid/) van het [Ministerie van Binnenlandse Zaken en Koninkrijksrelaties](https://organisaties.overheid.nl/9632/Binnenlandse_Zaken_en_Koninkrijksrelaties/).

## Organisatiestructuur

De [presentatie over Governance & Teams](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers/Gedeelde%20%20documenten/01%20-%20Programmadocumenten/02%20-%20Governance/Governance%20MOZa%20Programma.pptx?d=w583457a8a8dc4ccab412f94a85e25164) (slides 4 en 5) legt de structuur visueel uit.

## Stuurgroep

De stuurgroep houdt toezicht op de uitvoering van het programma en helpt het team om de vastgestelde doelen te realiseren. De stuurgroep bestaat uit directeuren van organisaties die deelnemen in de kopgroep van MOZa. Niet elk lid in de kopgroep is vertegenwoordigd in de stuurgroep.

Taken van de stuurgroep:

- Draagvlak binnen eigen organisatie en ambassadeur richting andere organisaties
- Beschikbaar stellen van capaciteit en prioriteit
- Daadwerkelijk aansluiten van de eigen organisatie op generieke dienstverlening die ontwikkeld wordt vanuit het programma MOZa

## Regieteam

Het regieteam coördineert de dagelijkse uitvoering van het programma. Het bestaat uit strategisch adviseurs en business consultants van organisaties in de kopgroep.

Taken van het regieteam:

- Meedenken over strategie en richting van de dienstverlening
- Afstemming tussen teams en helpen om problemen op te lossen
- Professionals uit de eigen organisatie laten aanhaken
- Onderzoeken en aansluitverzoeken coördineren

## Professionals

Naast het uitvoerende team werkt MOZa samen met professionals van binnen en buiten de overheid. Denk aan product owners, ontwikkelaars, UX-ers, architecten, juristen en business analisten. Zij komen van organisaties in de kopgroep, maar ook van andere overheidsorganisaties of van buiten de overheid.

Taken van de professionals:

- Meedenken over oplossingen
- Draagvlak uitwerken
- Testen met de eigen organisatie en deelname aan pilots

## MOZa productteam

Dit is het team dat dagelijks werkt aan MOZa. Het team wordt aangestuurd door een productmanager. Het team bestaat uit collega's die verschillende rollen vervullen:

- Architectuur
- Business analyse
- Communicatie
- UX-onderzoek
- Meerdere ontwikkelteams, elk met:
  - Product owner
  - Tech lead
  - UX-ontwerpers
  - Solution architect
  - Ontwikkelaars

Taken van het MOZa productteam:

- Uitwerken van klantreizen en use cases
- Ontwikkelen en testen van prototypes
- Pilots samen met dienstverleners
- Realiseren van alfa- en bètaversies
- Communicatie
- Organiseren van fieldlabs

Binnen het MOZa team zijn de verantwoordelijkheden als volgt beschreven:

### Eindverantwoordelijk

De **productmanager** is samen met de **opdrachtgever MinBZK** eindverantwoordelijk voor het programma.

### Inhoudelijk verantwoordelijk

Binnen MOZa wordt gewerkt aan meerdere digitale producten. Elk product heeft een eigen ontwikkelteam. De **product owner** is samen met **UX** (gebruikersonderzoeken) inhoudelijk verantwoordelijk voor het product.

### Technische teams

Het project bestaat uit verschillende technische teams. Elk team heeft een **tech lead** die verantwoordelijk is voor de technische keuzes binnen het team.

## Besluitvorming

We streven naar transparante besluitvorming:

### Operationele beslissingen

Het uitvoerende team neemt deze beslissingen. Dit gaat over hoe we iets bouwen of implementeren.

### Tactische beslissingen

Deze worden genomen door het regieteam. Dit gaat onder andere over prioriteiten en hoe we gezamenlijk invulling geven aan de ontwikkeling van generieke interactieservices die bijdragen aan het doel van de één overheidservaring.

### Strategische beslissingen

De opdrachtgever in samenwerking met productmanager en regieteam bereiden deze voor. De stuurgroep neemt vervolgens een beslissing. Dit gaat onder andere over richting en scope.

## Decision records

We zijn bezig met het opzetten van een systeem voor decision records. Dit zijn vastleggingen van belangrijke beslissingen met de context en overwegingen.

Dit helpt ons om:
- Later te begrijpen waarom we iets besloten hebben
- Nieuwe teamleden snel bij te praten
- Patronen in onze besluitvorming te zien

## Escalatie

Als er problemen zijn die niet op teamniveau opgelost kunnen worden:

1. **Eerst**: Bespreek het in het team of met de productmanager
2. **Dan**: Escaleer naar het regieteam
3. **Als laatste**: Escaleer naar de stuurgroep

Escaleren is geen teken van zwakte. Het zorgt ervoor dat problemen op het juiste niveau opgelost worden. Zo voorkomen we dat onopgeloste onderwerpen de ontwikkeling in de weg zitten.

## Vragen over governance?

Niet zeker wie verantwoordelijk is voor een beslissing of waar je iets moet neerleggen? Vraag het in Mattermost of stuur een bericht naar de productmanager.

## Het team

Het MOZa team bestaat uit verschillende disciplines die samenwerken aan MijnOverheid Zakelijk. Hier vind je informatie over de teamsamenstelling en hoe je mensen kunt bereiken.

## Smoelenboek

In onze samenwerkruimte staat het [MOZa Smoelenboek](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers/Gedeelde%20%20documenten/01%20-%20Programmadocumenten/11%20-%20Team/Smoelenboek%20MOZa.pptx?web=1). Hier vind je contactgegevens van alle teamleden.

Het smoelenboek is handig om:
- Namen en gezichten te koppelen
- Te zien wie welke rol heeft
- Contactgegevens snel te vinden

## Contactpersonen

Op de [samenwerkruimte](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers) staat een lijst met contactpersonen en hun verantwoordelijkheden.

## Governance

Naast het uitvoerende team zijn er ook overlegstructuren:

- **Stuurgroep** - Neemt belangrijke beslissingen en is er om ons te helpen
- **Regieteam** - Denkt strategisch mee en koppelt kennis aan het programma

Verslagen van deze overleggen vind je in de samenwerkruimte onder programmadocumentatie.

Meer over de governance en organisatie vind je in de sectie [over MOZa](/over-moza/index.md).

## Bereikbaarheid

De beste manier om teamleden te bereiken is via [Mattermost](/handboek/jouw-start/accounts-en-tools/index.md#mattermost). Daar is iedereen dagelijks actief.

Voor formele zaken of langere berichten kun je ook e-mailen. De e-mailadressen vind je in het [smoelenboek](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers/Gedeelde%20%20documenten/01%20-%20Programmadocumenten/11%20-%20Team/Smoelenboek%20MOZa.pptx?web=1).

## Nieuwe teamleden

Als er nieuwe teamleden bij het team komen, wordt dit aangekondigd in Mattermost en de MOZa Weekly. Zo weet iedereen wie er bij is gekomen.

## Accounts en tools

Om goed te kunnen samenwerken bij MOZa, heb je toegang nodig tot een aantal tools. Hieronder vind je een overzicht van de belangrijkste systemen.

## Mattermost

We gebruiken Mattermost voor dagelijkse communicatie. Hier vind je alle teamleden en kun je vragen stellen, updates delen en meepraten over lopende onderwerpen.

- **Link**: [digilab.overheid.nl/chat/mijnoverheid-zakelijk](https://digilab.overheid.nl/chat/mijnoverheid-zakelijk)
- **Gebruik**: Dagelijkse communicatie, vragen, updates
- **Let op**: Je hebt een Pleio-account nodig voor toegang (zie de notitie hieronder)

 Mattermost instellen
> Zorg ervoor dat je [Mattermost hebt geïnstalleerd](https://mattermost.com/apps/) en volg deze stappen:
>
> 1. [Registreer een nieuwe account op Pleio](https://realisatieibds.pleio.nl/register)
> 2. [Login](https://digilab.overheid.nl/chat/login) → GitLab → Pleio
>    - of configureer de volgende server in Mattermost en volg de instructies: `https://digilab.overheid.nl/chat`
> 3. [Ga naar het MOZa kanaal](https://digilab.overheid.nl/chat/mijnoverheid-zakelijk/) of [vraag ons om je toe te voegen](mailto:moza@minbzk.nl) aan het team

## GitHub

We gebruiken GitHub voor code, documentatie en planning. Zoveel mogelijk van onze code werken we open aan. Het is handig om hier rekening mee te houden.

 GitHub account aanmaken
> GitHub is een openbaar platform. Als je nog geen account hebt:
>
> 1. [Maak een account aan op github.com](https://github.com/signup) met je rijksoverheid e-mailadres
> 2. Kies een gebruikersnaam, waarbij je voor privacy een naam kunt kiezen die niet herleidbaar is naar jouw persoon
> 3. Mail [OpenSource@MinBZK.nl](mailto:OpenSource@MinBZK.nl) met de vraag om toegevoegd te worden aan de MinBZK organisatie
> 4. Vraag daarna een teamlid om je toe te voegen aan het MOZa team en eventueel aan specifieke repositories
>
> Heb je al een account? Check of zorg dat je rijksoverheid e-mailadres gekoppeld is en volg stap 3 en 4 hierboven.

### Repositories

Alle MOZa-repositories hebben de tag `mijnoverheidzakelijk`:

- **Link**: [github.com/topics/mijnoverheidzakelijk](https://github.com/topics/mijnoverheidzakelijk)
- **Gebruik**: Code, documentatie, issues

### Project boards

We gebruiken GitHub Projects voor planning en overzicht:

- [**Alle boards**](https://github.com/orgs/MinBZK/projects/40/)
- [**MOZa Fase 3**](https://github.com/orgs/MinBZK/projects/40/views/19)

Op het MOZa Fase 3 bord houden we in hoofdlijnen bij hoe het staat met het plan voor deze fase. Voor gedetailleerde taken zijn er aparte boards voor UX, Development, Communicatie, Architectuur en Research.

## Samenwerkruimte

De Samenwerkruimte is onze centrale plek voor programmadocumentatie, presentaties, verslagen en andere documenten.

- **Link**: [samenwerkruimten.nl MOZa](https://www.samenwerkruimten.nl/teamsites/programma%20mijnoverheid%20voor%20ondernemers/)
- **Gebruik**: Programmadocumentatie, presentaties, verslagen en overige documenten

Hier vind je onder andere:
- Verslagen van de Stuurgroep en het Regieteam
- Presentaties en roadmaps
- Het smoelenboek met contactgegevens
- De contentkalender

## Andere tools

Afhankelijk van je rol kun je ook toegang nodig hebben tot:

- **Figma** - Voor UX/design work
- **Lucidspark** - Voor brainstormen en visueel samenwerken

Vraag een collega welke tools voor jouw werk relevant kunnen zijn.

## Hulp nodig?

Als je ergens geen toegang toe hebt of problemen ondervindt, vraag het in Mattermost of tijdens een samenwerkdag.

## Facilitaire diensten

Voor je sessies en bijeenkomsten regel je een aantal praktische zaken zelf. Hieronder lees je hoe je een ruimte reserveert en waar je terecht kunt voor de spullen die je nodig hebt.

## Ruimte reserveren

Ruimtes reserveer je op het facilitair portaal [CFD](https://fmis.belastingdienst.nl/). Reserveer op tijd, want ruimtes zijn niet altijd beschikbaar.

- Via CFD boek je ruimtes van het Rijk (de zogeheten Rijkshubs). Deze zijn gratis te boeken.
- Heb je een ruimte op een andere locatie nodig? Het secretariaat ([RIG@Rijksoverheid.nl](mailto:RIG@Rijksoverheid.nl)) kan betaald ruimtes reserveren op andere locaties.

## Sessie benodigdheden

Op elke verdieping van het Beatrixpark staat standaard een kast met materialen. Denk aan pennen, stiften, post-its en meer.

Mis je iets? Neem contact op met Mahjouba Amtyi via [Mahjouba.Amtyi@rijksoverheid.nl](mailto:Mahjouba.Amtyi@rijksoverheid.nl).

## Locatie

Je vindt het Beatrixpark op:

Wilhelmina van Pruisenweg 52  
2595 AN Den Haag

## Geschiedenis

## Slim Geregeld, Goed Verbonden (2007 - 2012)

Al in 2007 startte het programma [Slim Geregeld, Goed Verbonden](https://nl.wikipedia.org/wiki/Slim_geregeld,_goed_verbonden) in opdracht van het Ministerie van Economische Zaken (EZ). Het doel: minder regeldruk voor ondernemers door betere samenwerking tussen overheidsorganisaties en het bedrijfsleven. Uit dit programma ontstond het **Ondernemingsdossier**: het idee dat een ondernemer gegevens één keer invoert en de overheid deze hergebruikt.

## MijnOverheid voor Ondernemers (2015 - 2019)

In 2015 zegde Minister Henk Kamp (EZ) toe om het Ondernemingsdossier door te ontwikkelen naar MijnOverheid voor Ondernemers (MOvO). In 2016 stelde het programma zijn [doelen](https://zoek.officielebekendmakingen.nl/kst-29515-397.html) vast en startten de KVK en UWV met de uitvoering.

In 2019 werd een basisversie opgeleverd in de vorm van een "assistent" en getest met een beperkt aantal ondernemers. Het project werd in september 2019 [formeel afgerond](https://www.rijksictdashboard.nl/ict-activiteiten/b33ce2ae-9aa6-42bc-bd2b-b721b2918471/binnenlandse-zaken-en-koninkrijksrelaties-mijnoverheid-voor-ondernemers). De geplande vervolgstappen zijn niet gerealiseerd.

## Een nieuwe start (2024 - heden)

In 2024 is het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties samen met de Belastingdienst, RVO, KVK, Douane, VNG en Logius gestart met een ontwerpend onderzoek in het kader van MijnOverheid voor ondernemers. Het doel van dit onderzoek was het vormgeven van de visie op de digitale “1 overheidsbeleving” voor ondernemers, zoals ook afgesproken in de Werkagenda Waardengedreven Digitaliseren en de huidige voorgenomen focus in de Nederlandse Digitaliseringsstrategie (NDS).

In dit onderzoek is er in diverse co-creatie sessies met 75 ondernemers (MKB tot 50 medewerkers en ZZP'ers) gesproken. Ook zijn de behoeften en ideeën opgehaald van diverse overheidsorganisaties. Dit heeft de basis gevormd van het programma MijnOverheid Zakelijk.

## Hybride samenwerken

We werken hybride bij MOZa. Dat betekent dat je zowel thuis als op locatie kunt werken. We hebben twee vaste samenwerkdagen per week waar we fysiek samenkomen. Maandag is de belangrijkste dag. Woensdag is nice to have en vaak ook een moment om samen te werken met andere teams. Probeer minimaal één dag per week bij het team aan te haken.

## Vaste dagen

### Maandag - Digi Vloer Den Haag

Op maandagen komen we samen in Den Haag bij Digi Vloer, naast NS station Den Haag Laan van NOI.

- **Wanneer**: Elke maandag
- **Waar**: Digi Vloer Den Haag (naast NS station Den Haag Laan van NOI)

### Woensdag - Dev.loer Utrecht

Op woensdagen komen we samen bij Dev.loer in Utrecht.

- **Wanneer**: Elke woensdag
- **Waar**: Dev.loer Utrecht
- **Let op**: Deze locatie is tijdelijk gesloten, een nieuwe locatie volgt

## Werkplek reserveren

Reserveer altijd van tevoren een werkplek. Je vindt het reserveringssysteem in [Mattermost](/handboek/jouw-start/accounts-en-tools/index.md#mattermost) onder Digilab. Geen toegang? Vraag een collega om je toe te voegen.

**Tip**: Reserveer tijdig, vooral voor drukke dagen.

## Waarom samenwerkdagen

De samenwerkdagen zijn belangrijk voor:

- **Persoonlijk contact** - Elkaar leren kennen en samenwerken
- **Overleg** - Complexe onderwerpen bespreken gaat makkelijker face-to-face
- **Teamgevoel** - Samen brainstormen, lunchen en koffie drinken

Je bent niet verplicht om aanwezig te zijn, maar we moedigen het wel aan om een dag per week samen te werken. Het helpt om betrokken te blijven bij het team en de voortgang.

## Thuiswerken

De overige dagen kun je thuiswerken. Soms vragen we je om voor een meeting naar locatie te komen.

# Weekly Updates

De laatste 10 updates. Voor alle updates, zie [/weekly/llms-full.txt](/weekly/llms-full.txt).

## MOZa Weekly 3 september 2026 (3 september 2026)

## Algemeen

* **De Weekly is terug:** na de zomerstop pakken we de wekelijkse update weer op. Deze editie kijkt terug op augustus.
* **Visualisatie van de online dienstverlening:** we sloten aan bij een visualisatiesessie over de overheidsbrede online dienstverlening. De visualisatie neemt collega's mee in de strategie en is bedoeld als toegankelijker alternatief voor een beleidsstuk.
* **Templates voor ons werk:** we maken voortaan onderscheid tussen analyses en functionele beschrijvingen, en maakten daar templates voor. Ook voor stories ligt er nu een template. We gaan uitproberen wat goed werkt en wat past bij hoe wij ons werk aan het organiseren zijn.
* **Team groeit verder:** per 1 september kregen we versterking op het werk dat vanuit beleid moet gebeuren. Op 14 september start een business analist. We zoeken nog versterking in de hoek van software- en AI-engineering.

## Gebruikersonderzoek

* **Digitale assistent getest met ondernemers:** op 25 en 26 augustus onderzochten we of een AI-assistent ondernemers echt helpt bij regeldruk. We gebruikten de energiebesparingsplicht als voorbeeld. Vijf van de zes deelnemers waren enthousiast en vonden de assistent betrouwbaar. Dat laatste ging tegen onze verwachting in. Het onderzoeksrapport volgt.
* **Waar ondernemers hulp bij willen:** het eerste deel van het onderzoek ging over hoe ondernemers nu aan hun informatie komen. Deelnemers gaven aan dat ze vooraf willen weten welke gegevens ze nodig hebben, of dat ze daarbij geholpen willen worden.
* **Onderzoeken op één plek:** we spraken met de Kamer van Koophandel en Logius af dat we gebruikersonderzoeken voortaan publiceren op [gebruikersonderzoeken.nl](https://gebruikersonderzoeken.nl/). Logius begint met de onderzoeken van MOZa.

## Notificatiedienst

* **Sessie op Common Ground:** op dinsdag 15 september organiseren we tijdens Common Ground een sessie over de [notificatiedienst](/onderwerpen/notificatiedienst/index.md). Een manier om de samenwerking met de gemeenten verder op te zoeken. Logius sluit hier ook aan, zodat we de samenwerking en wat hier uit volgt direct goed kunnen borgen.
* **Contactherstel wordt concreter:** we werkten onze analyse van de contactherstelservice van Logius verder uit en bespraken die met hen. Er ligt nu een beschrijving van de wijzigingen die nodig zijn om die service aan het Notificatie Management Component (NMC) te koppelen.
* **Securityreview verder ingericht:** we stemden met de Auditdienst Rijk (ADR) en Logius af hoe we de securityreview organiseren. We willen al onze services laten doortesten.
* **Aansluiten op NotifyNL bij Logius:** ons IP-adres staat nu op de witte lijst van de Logius Private Cloud. De volgende stap is de koppeling zelf.
* **Keuzes vastgelegd:** we schreven een architectuurbesluit over de vraag of we de notificatieketen inrichten als orkestratie of met events. Ook scherpten we het NMC aan: callback-URL's worden nu gecontroleerd, zodat ze niet te misbruiken zijn om interne adressen te benaderen.

## Profieldienst

* **Verwijderen zonder gegevens te wissen:** je kunt contactgegevens en voorkeuren nu 'zacht' verwijderen. Ze verdwijnen uit beeld, maar blijven bewaard. Verwijder je het laatste gegeven van een partij, dan verdwijnt die partij mee. Hierbij houden we ook rekening met de AVG: gegevens kunnen altijd volledig verwijderd worden.
* **Eerst het contract:** de API van de [profieldienst](/onderwerpen/profielservice/index.md) komt nu volledig uit de OpenAPI-specificatie (het contract), zowel de datamodellen als de interfaces. Testen bewaken dat de code niet stilletjes van het contract afwijkt.
* **Pseudoniemen echt onraadbaar:** in het logboek dataverwerkingen leggen we niet vast om wie een verwerking ging met het identificerende nummer zelf, zoals een BSN of KvK-nummer, maar met een pseudoniem. Dat pseudoniem was met genoeg rekenkracht te herleiden naar het oorspronkelijke nummer. Nu berekenen we het met een geheime sleutel, waardoor dat niet meer kan. Dezelfde persoon of organisatie houdt wel steeds hetzelfde pseudoniem.
* **Op ZAD en in beeld:** de profieldienst draait nu op het [ZAD-cluster](https://zad.rijksapp.nl/) bij ODC-Noord. We maakten dashboards zodat we zien wat de dienst doet, en trokken de databases voor de ontwikkel-, test- en productieomgeving gelijk.
* **Achterstallig onderhoud weggewerkt:** we gingen over naar Java 25, werkten veel updates weg en ruimden de repository's op. Ook controleren we de invoer strenger.
* **Teststrategie in de maak:** we werken een teststrategie uit op basis van de testpiramide. De opzet voor de unit-tests is klaar, de andere lagen volgen.
* **DPIA en wensen van gemeenten:** we voorzagen de nieuwe versie van de DPIA (privacytoets) van commentaar. Er zijn nog stappen nodig om die verder te brengen. Openstaande wensen van de gemeente Amsterdam koppelden we aan tickets, zodat ze worden opgepakt.

## Berichten

* **Werkgroep Berichten start:** Logius in samenwerking met MOZA richt een werkgroep op rond berichten. Onder ander de Belastingdienst en VNG nemen hier al aan deel. Het eerste overleg met de architecten staat gepland. Doel is toewerken naar een praktische pilot en een routekaart.
* **Proeftuin en stelsel gekoppeld:** de [proeftuin](/onderwerpen/proeftuin/index.md) haalt berichten nu op uit de proefopstelling van het [Federatief Berichtenstelsel](/onderwerpen/berichten-fbs/index.md). De Berichtenbox toont niet langer vaste voorbeelden, maar gegevens uit het stelsel. Vallen we terug op verzonnen berichten, dan is dat voortaan zichtbaar.
* **Demo-console voor het stelsel:** we bouwden een console waarmee we scenario's kunnen laten zien, zoals berichten ophalen.
* **Honderd magazijnen tegelijk:** ons simulatie-magazijn bootst meerdere berichtenmagazijnen tegelijk na. We hebben nu een profiel met honderd magazijnen, waarvan er twee plat liggen en vier traag zijn. Zo kunnen we laten zien wat er gebeurt als het misgaat.
* **De keten loopt federatief:** het ophalen van berichten gaat via [Federated Service Connectivity (FSC)](https://fsc-standaard.nl/hoe-werkt-fsc/), van het opzetten van contracten tussen uitvraag en magazijnen tot het doorsturen van notificaties.

## Machine-uitvoerbare wetgeving en digitale assistent

* **Klaar voor het onderzoek:** we maakten de [digitale assistent](/onderwerpen/digitale-assistent/index.md) klaar voor het gebruikersonderzoek. De assistent heeft nu één vast karakter, geeft duidelijke foutmeldingen en merkt op wanneer een vraag buiten zijn bereik valt. Ook bewaakt hij dat antwoorden op B1-niveau blijven, en legden we strakker vast wat het taalmodel doet en wat de RegelRecht-engine doet.
* **Zelf uitproberen:** je kunt de assistent bekijken in de [proeftuin](https://proef.moza.rijksapp.dev/moza/digitale-assistent/). Let op: zonder eigen "AI sleutel" krijg je vaste antwoorden en geen antwoorden van het taalmodel.
* **Meedenken over de AI-verordening:** we spraken met een expert op de AI-verordening en met een jurist over de digitale assistent. Dat leverde richting op voor de ontwikkeling en punten om rekening mee te houden.
* **Wetten en schema weer gelijk:** er zat verschil tussen de wetten die we hadden nagekeken en het nieuwe schema van RegelRecht. Dat hebben we rechtgezet.

## Logboek dataverwerkingen

* **Package voor iedereen beschikbaar:** versie 2.0 van ons [Logboek Dataverwerkingen-package](https://github.com/MinBZK/moza-logboekdataverwerking) staat nu op Maven Central. Zo kan iedereen het gebruiken.
* **Antwoord op een lastige vraag:** we vroegen Logius hoe je omgaat met een verwerking die achteraf mislukt. Het antwoord: schrijf de logregel vóór de verwerking en stop als dat schrijven niet lukt. Een logregel voor een verwerking die daarna mislukt, is beter dan geen regel. Bij een bulkverwerking mag je één samenhangend spoor gebruiken, maar schrijf wel een regel per betrokkene. Een klein voorbeeld waarom het nuttig is om zaken met elkaar te beproeven en op basis van inzichten vragen te stellen.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* MOZa teamdag - 8 september
* Regieteam - 9 september
* MOZa Pulse - 17 september
* Stuurgroep - 25 september

**Evenementen**

* [Common Ground Fieldlab](https://commonground.nl/events/view/1a31088b-5794-466c-8bf4-79be0a678eee/common-ground-fieldlab-14-en-15-september-2026) - 14 & 15 september, met onze sessie over de notificatiedienst op 15 september
* [Digilab meetup](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/b65a0a64-24cf-48cd-be27-61defd24c4e8/digilab-meetup) - 17 september
* [Symposium De European Business Wallet](https://ecp.nl/agenda/symposiumde-european-business-wallet-op-naar-eenvoudigere-overheidsdienstverlening-aan-bedrijven/) - 22 september
* [Technische briefing European Business Wallet en eIDAS-verordening](https://www.tweedekamer.nl/debat_en_vergadering/commissievergaderingen/details?id=2026A04729) - 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [UNFOLD #5](https://www.gebruikercentraal.nl/agenda/internationale-conferentie-digital-identity-wallets-van-idee-tot-implementatie-in-9-maanden/) - 7 & 8 oktober
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 29 juli 2026 (29 juli 2026)

## Algemeen

* **Vakantieperiode:** het is zomer en een deel van het team is met vakantie. Sommige onderwerpen blijven daardoor even liggen. Zo ook deze wekelijkse update. Eind augustus verschijnt er weer een nieuwe.
* **Logius vertelt over de samenwerking:** eerder meldden we al dat Logius de [intentieverklaring](/documenten/intentieverklaring/index.md) heeft getekend. Logius publiceerde hier nu een [nieuwsbericht](https://www.logius.nl/actueel/logius-sluit-aan-bij-samenwerking-voor-mijnoverheid-zakelijk) over. Een mooie manier om de samenwerking aandacht te geven.
* **Sprint 6 afgerond, sprint 7 gestart:** we rondden sprint 6 goed af en namen weinig werk mee naar de volgende ronde. In sprint 7 gaan we verder met onder andere een uitbreiding van het Notificatie Management Component (NMC): het toevoegen van notificatie-initiatie.

## Notificatiedienst

* **Pagina over de notificatiedienst online:** we publiceerden de informatie die we de afgelopen periode opbouwden op de pagina over de [notificatiedienst](/onderwerpen/notificatiedienst/index.md). Hiermee willen we meer inzicht geven in waar we aan werken. We werken de pagina bij zodra we nieuwe inzichten hebben. Ook [de documentatie](https://docs.mijnoverheidzakelijk.nl/workspace/documentation/Notificatiedienst) over dit onderwerp heeft een update gekregen.
* **Decentraal profiel:** je kunt het NMC nu ook gebruiken met een zogenaamd decentraal profiel. Ofwel: de dienstverlener levert zelf het e-mailadres aan waar de notificatie naartoe moet.
* **NMC en OMC naast elkaar gelegd:** we maakten een technische vergelijking tussen het voorstel voor het NMC en het Outputmanagementcomponent (OMC), als aanvulling op de eerdere functionele vergelijking. Aanleiding waren vragen vanuit de VNG en een aantal gemeenten. De uitkomst nemen we mee in toekomstige gesprekken met deze organisaties.
* **RVO verkent de aansluiting:** in een sessie met RVO spraken we over de notificatiedienst. Dit volgen we de komende periode op.
* **Contactherstel verkend:** we deden een eerste analyse van de contactherstelmodule van Logius en onderzoeken hoe we die aan het NMC kunnen koppelen. We wachten nog op documentatie voordat we hier verder mee kunnen gaan.
* **Securityreview in voorbereiding:** we stemden af met de Auditdienst Rijk (ADR) over een securityreview van de hele notificatiedienst. Na de zomer geven we dit samen verder vorm.

## Dienstverlenersportaal

* **Nieuwe persona's en een tweede klantreis:** we werken aan zes nieuwe [persona's](https://cx-moza.rijksapp.dev/personas/index.html) en een klantreis voor [het afnemen van de notificatiedienst](https://cx-moza.rijksapp.dev/klantreizen/afnemen-notificatiedienst/index.html). Allebei nog in concept. De persona's kregen daarbij een nieuwe look.
* **Versnellen met AI:** voor het maken van deze persona's en klantreizen gebruiken we AI. Doordat we onze werkwijze goed vastleggen, merken we dat we nu versnellen. Die werkwijze bewaren we als skill: een vaste set instructies waarmee de AI steeds op dezelfde manier werkt. Deze skill stellen we straks ook beschikbaar.
* **Federatief aansluiten uitgeplozen:** voor de klantreis verdiepten we ons in het aansluitproces. We keken naar het proces van Digipoort. De volgende stap is dit verwerken in de klantreis en in het concept van het dienstverlenersportaal.
* **Vergelijking met EVA:** Logius heeft de afgelopen periode gewerkt aan Eenvoudig Aansluiten (EVA). Vanuit MOZa denken we ook na over wat nodig is om dienstverleners aan te sluiten. Om kennis uit te wisselen en van elkaar te leren gaven we demo's van EVA en van het [concept dienstverlenersportaal](https://dienstverlener-moza.rijksapp.dev/).
* **Inloggen kan op vele manieren:** in het verlengde van de kennisuitwisseling met EVA zagen we een verschil. Zij gaan uit van inloggen met eHerkenning, wij kijken naar Single Sign-On (Rijks)overheid. Zakelijke gebruikers loggen op verschillende manieren in. Daar houden we in het concept van het dienstverlenersportaal ook rekening mee. We volgen daarbij de ontwikkelingen rond [GovConext](https://govroam.nl/diensten-govconext/govconext/), dat een oplossing biedt waarbij meerdere organisaties zich kunnen aansluiten.

## Profieldienst

* **Profieldienst nu via FSC:** we bouwden de keten met [Federated Service Connectivity (FSC)](https://fsc-standaard.nl/hoe-werkt-fsc/) op het [ZAD-cluster](https://zad.rijksapp.nl/) verder uit. We bevragen de profieldienst nu ook via FSC.

## Berichten

* **Demo-engine voor de Berichtenbox:** we begonnen aan een demo-engine waarmee we scenario's voor de Berichtenbox kunnen laten zien. Denk aan berichten ophalen, verplaatsen naar een map of verwijderen. Maar ook aan minder prettige situaties: een berichtenmagazijn dat traag is of niet reageert, of een nieuw bericht dat binnenkomt tijdens je sessie.

## RegelRecht en digitale assistent

* **Validatie met de editor:** we bereidden onze volgende afspraak met RVO over het [Financieel CV](https://regelhulpenvoorbedrijven.nl/financieelcv/) voor en zetten weer een stap in de validatie met de RegelRecht editor. Ook begonnen we met het verwerken van de input uit de vorige afspraak.
* **AI-Act-classificatie:** samen met het AI Gilde van het Rijks ICT Gilde maakten we een plan om de classificatie onder de AI-verordening rond te krijgen. Midden augustus maken we dit af.
* **Meer profielen in de proefopstelling:** voor de proefopstelling van de [digitale assistent](/onderwerpen/digitale-assistent/index.md) zetten we bedrijfsdata om naar meerdere profielen.

## Logboek dataverwerkingen

* **Package bijgewerkt:** we brachten ons [Logboek Dataverwerkingen-package](https://github.com/MinBZK/moza-logboekdataverwerking) op v1 van de LDV-standaard. Ook voegden we ondersteuning voor PostgreSQL toe en werkten we onderdelen bij om bekende kwetsbaarheden op te lossen.

## Wie mag wat

* **Federatieve concepten:** we verdiepten ons in de federatieve concepten achter de vraag "wie mag wat". De oplossing is er nog niet, maar de puzzelstukjes worden langzaam duidelijker.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Regieteam - 3 september
* MOZa teamdag - 8 september (inclusief afsluiter met MOZa regieteam)
* MOZa Pulse - 17 september
* Stuurgroep - 25 september

**Evenementen**

* [Common Ground Fieldlab](https://commonground.nl/events/view/1a31088b-5794-466c-8bf4-79be0a678eee/common-ground-fieldlab-14-en-15-september-2026) - 14 & 15 september
* [Symposium De European Business Wallet](https://ecp.nl/agenda/symposiumde-european-business-wallet-op-naar-eenvoudigere-overheidsdienstverlening-aan-bedrijven/) - 22 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 22 juli 2026 (22 juli 2026)

## Algemeen

* **Stuurgroep met demo van de notificatieketen:** in de stuurgroep van 16 juli lieten we een demo zien met een fictieve applicatie bij een dienstverlener: een zaaksysteem voor vergaderstukken dat uitnodigingen verstuurt. Toen we op verzenden drukten, liep de hele keten. Vanuit het systeem van de dienstverlener ging het bericht naar het Notificatie Management Component (NMC), langs de [profieldienst](/onderwerpen/profielservice/index.md) voor het e-mailadres, en via NotifyNL naar de mailbox van de stuurgroep. De applicatie kon daarna de bezorgstatus uitlezen.
* **Componentenoverzicht en scenario's rondom berichten:** aan de hand van het nieuwe componentenoverzicht voor de notificatie- en profieldienst bespraken we de stand van zaken met de stuurgroep. Een van de uitkomsten: we werken samen scenario's uit rondom berichten, notificeren en profiel, inclusief wat dat betekent voor de ondernemer.
* **Verkenning met MijnAmsterdam:** we spraken met de product owner van MijnAmsterdam en kregen een demo. MijnAmsterdam wordt vooral door inwoners gebruikt en minder door ondernemers. Veel diensten zijn wel digitaal, maar staan buiten de Mijn-omgeving. We verkennen of het centraliseren van enkele diensten winst kan opleveren. De MijnAmsterdam-omgeving is bovendien open source. Daarom bekijken we of we die kunnen toevoegen aan de [MOZa-proeftuin](/onderwerpen/proeftuin/index.md).
* **Team groeit:** deze maand startte een nieuwe architect om MOZa te ondersteunen. Daarnaast starten er per 1 september twee nieuwe collega's: een opgavemanager en een business analist.

## Gebruikersonderzoek

* **Berichtenbox getest met ondernemers:** op 13 en 14 juli deden we gebruikersonderzoek naar de Berichtenbox. We spraken zes ondernemers: een mix van zzp'ers en klein-mkb uit verschillende branches. Met een prototype liepen we scenario's door, zoals inloggen op MOZa, een bericht openen, en switchen tussen de Berichtenbox van de Belastingdienst en die van MOZa. De uitgebreide resultaten volgen later. [Bekijk het prototype](https://proef.moza.rijksapp.dev/ux-onderzoek/juli-2026/).
* **Twee thema's uitgelicht:** in het onderzoek stonden twee thema's centraal. Het federatieve stelsel: dezelfde berichten tegelijk tonen bij de Belastingdienst en bij MOZa. En actiegerichte berichten: bijvoorbeeld direct vanuit een bericht je aangifte doen. Over de veiligheid hiervan werden zorgen geuit. Daarover gaan we met elkaar in gesprek en we zorgen dat de juiste expertise aanhaakt.

## Notificatiedienst

* **MVP met de Belastingdienst:** in een requirementsessie met de Belastingdienst bespraken we de input voor een eerste MVP. We toonden ook de huidige stand van het NMC.
* **Centrale en decentrale regie:** in een overleg met VNG, Belastingdienst en Logius deelden we de uitgangspunten voor de notificatiedienst. Er lijkt overeenstemming dat de regie zowel centraal als decentraal moet plaatsvinden. Een terugkoppeling vanuit de architectuur volgt. We werken alvast aan een decentraal aansluitpunt in het NMC.
* **Werken met NotifyNL:** we zochten uit hoe en wanneer we NotifyNL van Logius kunnen gebruiken en spraken met het team daarachter. Ook lukte het om niet-verzonden e-mails opnieuw aan te bieden. Een deel van die aanpak kunnen we hergebruiken.
* **Uitgangspunten en documentatie:** er gebeurt veel, dus we besteden aandacht aan het bijhouden van de requirements, uitgangspunten en openstaande vragen. Zo werken we stap voor stap verder. Ook zorgen we dat de open documentatie op korte termijn weer is bijgewerkt.
* **Beheer en bewaking:** we maakten extra monitoringdashboards die onze services in de gaten houden. Dit doen we in lijn met de Logius-voorkeuren. Zo bereiden we ons voor op de overgang naar de Logius Private Cloud.

## Dienstverlenersportaal

* **Concept dienstverlenersportaal:** in de stuurgroep lieten we ook een praatstuk over het dienstverlenersportaal zien. De kern: dienstverleners moeten eenvoudig kunnen aansluiten, met gemak voor developers, inzicht in wat er gebeurt via een logboek en een duidelijk proces voor governance. Je kunt er zelf doorheen klikken op [dienstverlener-moza.rijksapp.dev](https://dienstverlener-moza.rijksapp.dev/). Let op: dit is een praatstuk om snel beelden bij elkaar te brengen en input op te halen, zodat we van daaruit het goede gesprek kunnen voeren.
* **Templatebibliotheek voor notificaties:** in NotifyNL zitten templates en we denken na over hoe je centrale en decentrale templates kunt organiseren. In het concept namen we voor nu een bibliotheek met templates op: met de standaard notificatieteksten van MijnOverheid en een eigen template voor een specifieke applicatie.

## Profieldienst

* **DPIA verder ingevuld:** we werkten samen met de juristen verder aan de DPIA (privacytoets) van de [profieldienst](/onderwerpen/profielservice/index.md) en verwerkten aanvullende punten.
* **Inhaalsprint gepland:** de afgelopen periode lag de nadruk op de notificatiedienst. Voor de profieldienst plannen we daarom een inhaalsprint in de komende periode, zodat we de nieuwste inzichten verwerken.

## Berichten

* **FSC-keten voor de Berichtenbox compleet:** we maakten de keten met [Federated Service Connectivity (FSC)](https://fsc-standaard.nl/hoe-werkt-fsc/) voor de Berichtenbox op het [ZAD-cluster](https://zad.rijksapp.nl/) compleet. Er draait nu een berichtenmagazijn dat via FSC wordt aangeboden, en een onderdeel dat zulke magazijnen kan aanroepen. Het uitvraagsysteem van het [Federatief Berichtenstelsel](/onderwerpen/berichten-fbs/index.md) loopt via dat onderdeel naar de magazijnen. Een tweede magazijn volgt binnenkort.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* MOZa teamoverleg - 28 juli
* Regieteam - 6 augustus (mogelijk september vanwege de vakantieperiode)
* MOZa teamdag - 8 september (inclusief afsluiter met MOZa regieteam)
* MOZa Pulse - 17 september
* Stuurgroep - 25 september

**Evenementen**

* [Common Ground Fieldlab](https://commonground.nl/events/view/1a31088b-5794-466c-8bf4-79be0a678eee/common-ground-fieldlab-14-en-15-september-2026) - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 15 juli 2026 (15 juli 2026)

## Algemeen

* **Actualiteitenservice gedocumenteerd:** we voegden de [actualiteitenservice](/onderwerpen/actualiteitenservice/index.md) toe aan de onderwerpen op deze site. Op de pagina lees je wat de service beoogt te doen, wat we bouwden en testten, en waarom we de verdere ontwikkeling nu pauzeren. Ook van werk dat we bewust stilzetten delen we zo de lessen.
* **Componentenoverzicht notificatie- en profieldienst:** met dit componentenoverzicht geven we inzicht in de stand van zaken van de componenten die onderdeel uitmaken van de notificatie- en profieldienst. Daarbij ook specifiek aandacht voor de uitdagingen waar we tegen aanlopen, de risico's en overige aandachtspunten. We zoeken nog een goede manier om rapportages zoals deze breder te delen.
* **Stuurgroep voorbereid:** we bereidden de stuurgroep van 16 juli voor. Op de agenda staan onder andere een demo van de notificatiedienst en dienstverlenersportaal. En we bespreken de stand van zaken aan de hand van het componentenoverzicht.
* **Afspraken met VNG:** we maakten procesafspraken met de VNG over hoe zij hun inbreng leveren. De afstemming wordt frequenter, waarbij we elkaar de komende periode elke week spreken.
* **Sprint FAQ 2.0:** we faciliteerden een vernieuwde opzet van onze eigen sprint FAQ. Onze teams delen vooraf een filmpje, link of presentatie over de afgelopen sprint. Tijdens het overleg zelf is er zo meer ruimte voor vragen. Itererend komen we tot een goed concept voor kennisdeling. Het juridische team van BZK is voortaan ook uitgenodigd voor de sprint FAQ, zodat zij al eerder een beeld kunnen vormen over wat er speelt binnen MOZa.
* **Ontwikkelen met AI-ondersteuning:** we kregen vragen over hoe wij software bouwen met AI-ondersteuning en of dit vanuit risicoperspectief wel goed gaat. Ons korte antwoord is dat de mens verantwoordelijk blijft en de kwaliteit van de software inclusief code op elk moment door anderen kan worden beoordeeld. Goede vragen helpen ons om deze nieuwe manier van werken scherp uit te blijven leggen.

## Notificatiedienst

* **NMC klaar voor de demo:** het Notificatie Management Component (NMC) is klaar voor de demo in de stuurgroep. De NMC praat nu met de acceptatie-omgeving van de [profieldienst](/onderwerpen/profielservice/index.md). De hele flow werkt: een notificatieverzoek wordt verstuurd vanuit het systeem van een dienstverlener naar het NMC. Het NMC zoekt het e-mailadres op in de profieldienst, verstuurt de e-mail via NotifyNL en geeft de bezorgstatus terug aan de dienstverlener.
* **Juridisch spoor:** we brachten in kaart of een basisversie van de notificatiedienst per 1 januari 2027 live kan op basis van de huidige wetten. Hierover hebben we gesproken met het juridische team van BZK. Daarnaast hebben we ook een hulpvraag uitgezet bij het MOZa regieteam en trekken we hierin samen op met Obis.
* **Sjablonen per berichttype:** een dienstverlener kan bij een notificatie nu een type bericht meegeven. Het NMC koppelt dat type automatisch aan het juiste e-mailsjabloon.
* **Automatisch uitrollen:** het NMC rolt nu automatisch uit naar het ZAD-cluster bij elke goedgekeurde wijziging in de code. Hiermee kunnen we altijd de laatste versie testen.
* **Beheer en bewaking:** we richtten de alerting en health checks verder in, zo dicht mogelijk bij hoe de beheeromgeving bij Logius er straks uit moet zien. Bij het testen van foutmeldingen van NotifyNL zagen we onverwacht gedrag; we hebben de vraag bij NotifyNL uitgezet.

## Profieldienst

* **Reactie op DPIA:** de juristen reageerden op de DPIA (privacytoets) van de profieldienst. We pakken de opvolging hiervan op.
* **Kwaliteitscontroles uitgebreid:** we werkten de automatische controles op de code verder uit, zoals linting en checks op bekende kwetsbaarheden.
* **Gesprekken met de KVK:** we spraken opnieuw met de KVK en hebben daarbij gesproken over de positionering van de profieldienst. Daarbij deden we nieuwe inzichten op over de wettelijke positionering. Ook kan de KVK de profieldienst, of onderdelen daarvan, gebruiken in het eigen landschap.

## Berichten / FBS

* **Berichtenbox via FSC:** we werkten aan het ontsluiten van de Berichtenbox-proefopstelling via [Federated Service Connectivity (FSC)](https://fsc-standaard.nl/hoe-werkt-fsc/) op het ZAD-cluster. Nog niet helemaal af, omdat er nog wat wijzigingen aan dit cluster nodig zijn.
* **Patroon van Vorderingenoverzicht Rijk verkend:** we maakten een eerste opzet die verkent hoe het patroon achter [Vorderingenoverzicht Rijk](https://vorijk.nl/docs/introductie/) gebruikt kan worden binnen het [Federatief Berichtenstelsel](/onderwerpen/berichten-fbs/index.md).

## Klantreizen en demo-omgeving

* **Proef en demo worden één:** we werkten een aanpak uit om toe te werken naar één proefomgeving waar alles op staat. Met een uitbreiding van de flags-functionaliteit zetten we versies naast elkaar. We stemmen met de MOZa teams af welke functionaliteiten van de demo-omgeving over kunnen naar de proefomgeving. Ook maakten we een testopzet om React-componenten in de proefomgeving te gebruiken.
* **Klantreis subsidieaanvraag groeit:** op de [CX omgeving](https://cx-moza.rijksapp.dev/) zetten we stappen met de klantreis voor de gezamenlijke subsidieaanvraag. We kunnen nu verschillende detailniveaus en vraagstukken tonen, zodat verschillende typen stakeholders er iets aan hebben. [Bekijk de sneak preview](https://cx-moza.rijksapp.dev/klantreizen/gezamenlijke-subsidieaanvraag/index.html) inclusief easter egg. Vind jij 'm?
* **MijnAmsterdam als proeftuin:** we verkennen of we de broncode van MijnAmsterdam lokaal kunnen draaien, zodat we kunnen experimenteren met MOZa-integraties in een bestaande MijnOmgeving. Parallel bekijken we of de proef met de browser-plugin een vervolg moet krijgen voor deze use case.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* MOZa Pulse - 16 juli
* Stuurgroep - 16 juli
* Regieteam - 6 augustus (mogelijk september vanwege de vakantieperiode)
* MOZa teamdag - 8 september (inclusief afsluiter met MOZa regieteam)

**Evenementen**

* [Common Ground Fieldlab](https://commonground.nl/events/view/1a31088b-5794-466c-8bf4-79be0a678eee/common-ground-fieldlab-14-en-15-september-2026) - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 8 juli 2026 (8 juli 2026)

## Algemeen

* **Statusoverzicht van bouwblokken:** we werken aan een overzicht van bouwblokken waar we momenteel aan werken, voor de Wet modernisering elektronisch bestuurlijk verkeer (WMEBV). Dit overzicht volgt de architectuur en laat per bouwblok zien welk team eraan werkt, wat de gewenste planning is en wat de uitdagingen zijn. We zoeken daarbij nog naar een vorm om dit ook publiek te delen.
* **MOZa Regieteam:** in het regieteam bespraken we de stand van zaken van de bouwblokken aan de hand van het statusoverzicht. We spraken onder andere over hoe we samen met andere organisaties verder werken: met gezamenlijke werksessies rond de notificatiedienst en met de mogelijkheid voor individuele verdieping per organisatie. Ook hebben we de stuurgroep van 16 juli voorbereid, met daarin onder andere het delen van de stand van zaken en een demo van de notificatiedienst.
* **Tijdlijnen aangescherpt:** voor de notificatie- en profieldienst hebben we de tijdlijnen voor de komende periode aangescherpt. We brachten daarbij lagen aan in de functionaliteiten. Van daaruit geven we aan wanneer het gewenst is dat een functionaliteit beschikbaar is. We brengen ook in kaart of dat juridisch, technisch en operationeel haalbaar is, of dat er nog uitdagingen zijn. Deze tijdlijnen verwerken we in het statusoverzicht.
* **Juristen eerder betrekken:** we gaan het juridische team van BZK eerder in het proces betrekken, zodat zij ook eerder een beeld kunnen vormen van wat eraan komt. Eerder betekent in dit geval: al vanaf het moment dat de gebruikersonderzoeken starten. Concreet laten we dit team aansluiten bij onze sprint-FAQ, zodat ze vroeg kunnen meekijken en meteen vragen stellen.
* **Portaal voor dienstverleners:** we werken aan een concept voor een portaal waar dienstverleners kunnen zien welke bouwblokken beschikbaar zijn. Denk hierbij aan de notificatie- en profieldienst. Het doel is dat je deze diensten eenvoudig kunt uitproberen en er in een latere fase op kunt aansluiten. Je kunt ze ook configureren en rapportages inzien, bijvoorbeeld over het gebruik.

## Gebruikersonderzoek

* **Berichtenbox klaar voor onderzoek:** we pasten de interface van de Berichtenbox in de proefopstelling aan voor het gebruikersonderzoek op 13 en 14 juli. We nemen gebruikers mee in een flow waar verschillende MijnOmgevingen worden ingezet. De acties vanuit de MijnOmgevingen werken daarbij synchroon: markeer je een bericht in het ene portaal, dan zie je dat ook in het andere portaal. Ter illustratie een mogelijke flow:
    * Je krijgt een bericht in je mailbox.
    * Via MijnOverheid ga je naar MijnOverheid Zakelijk en vindt daar het bericht.
    * Van daaruit klik je door naar Mijn Belastingdienst Zakelijk.
    * In Mijn Belastingdienst Zakelijk markeer je het bericht als belangrijk.
    * Op MijnOverheid Zakelijk staat dit bericht nu ook gemarkeerd.

## Notificatiedienst

* **Eerste ruwe versie van het NMC werkt:** we hebben een grote stap gezet met het Notificatie Management Component (NMC). De eerste ruwe versie draait op het [ZAD-cluster](https://zad.rijksapp.nl/). We konden echt e-mails versturen, met gegevens uit de [profieldienst](/onderwerpen/profielservice/index.md). Een mooie mijlpaal. We maakten ook een korte demo die de hele flow laat zien, van het versturen tot de status "bezorgd".
* **Zo werkt de flow:** een dienstverlener biedt een notificatie aan voor iemand met een BSN of KVK-nummer. Het NMC zoekt in de profieldienst de juiste partij en het e-mailadres op. Daarna stuurt het de notificatie naar NotifyNL, dat de e-mail bezorgt. NotifyNL koppelt terug of het bericht is afgeleverd. Die terugkoppeling spelen we door aan de dienstverlener.
* **Beheer en bewaking:** we werkten verder aan de health check- en alerting-service en bereidden de bewaking voor. Zo houden we de omgeving goed in de gaten richting lancering.
* **Toewerken naar lancering:** we spraken met Logius verder over hoe we de notificatiedienst kunnen laten landen. Hierover met elkaar in gesprek zijn is belangrijk, omdat er een breder team aan collega's betrokken moet worden op het moment dat we deze dienst bij Logius in beheer willen nemen. Nu er een eerste ruwe versie is, betekent dit ook dat we dit gesprek beter kunnen voeren.

## Profieldienst

* **Code review afgerond:** ondersteund door AI hebben we een code review van de profieldienst gedaan. De bevindingen staan als tickets op de backlog en worden opgepakt. Een aantal lessen hebben we meteen ook toegepast op het NMC.
* **Hergebruik van registers onderzocht:** we onderzochten of we een bestaand register kunnen hergebruiken in de profieldienst. Zo bekijken we of dat haalbaar en logisch is.

## Machtigen en mandaten

* **Werksessie "wie mag wat":** op 30 juni hielden we de werksessie over authenticatie, autorisatie, machtigen en mandaten. Met het team brachten we verschillende beelden en meningen bij elkaar. We werkten met persona's en zetten de eerste stappen naar een gezamenlijk beeld, waarbij nu ook veel aandacht uitgaat naar het vergroten van het kennisniveau. Zowel functioneel als technisch komen hierbij veel uitdagingen op tafel.
* **Klantreis in beeld:** we maakten een service blueprint voor de klantreis van het aanvragen van een subsidie, met de ondernemer centraal. Deze inzichten gebruiken we om het verhaal van "de overheid van de nabije toekomst" te verrijken.
* **Inzicht:** in een sessie over authenticatie en autorisatie leerden we dat RVO uitgaat van een "trusted party". Zolang een andere partij dezelfde taal spreekt, kan een koppeling al werken. De vraag blijft hoe we die taal spreken zonder dat er te veel dialecten ontstaan.
* **Vervolg gepland:** we plannen een vervolgsessie met een bredere groep. De eerste namen daarvoor kwamen al langs in het regieteam.

## Berichten / FBS

* **Aanpak en keuzes vastgelegd:** we voegden [een document](https://github.com/MinBZK/moza-poc-fbs-berichtenbox/blob/main/docs/aanpak-en-keuzes.md) toe dat onze aanpak en keuzes rond de proefopstelling van het Federatief Berichtenstelsel toelicht.
* **Samenwerking met Logius:** we hebben aan Logius en BZK toegelicht wat we het afgelopen halfjaar hebben gedaan. We zijn uitgegaan van de architectuur die al eerder voor FBS is uitgedacht, hebben die aangepast met de kennis van nu en maken daar nu een proefopstelling voor. Logius is nu goed aangehaakt op de proefopstelling en we zetten de samenwerking de komende tijd voort.
* **FBS draait op ZAD:** de proefopstelling draait nu in een eerste opstelling op het ZAD-cluster, met een nagebootste profieldienst. Zo bouwen we de omgeving stap voor stap op.
* **Implementatie FSC:** we werken aan [Federated Service Connectivity (FSC)](https://fsc-standaard.nl/hoe-werkt-fsc/) op het ZAD-cluster, met alle beveiliging die daarbij hoort. Samen met de collega's die aan ZAD werken, zorgen we dat ook aan het ZAD-cluster aanpassingen worden gemaakt. Dit proces verloopt snel, waardoor de basis voor FSC nu al draait.
    * **Nieuwtje over FSC:** FSC staat nu op een lijst van de Europese Commissie, te vergelijken met de Nederlandse "pas toe of leg uit". Dat bevestigt dat onze inzet op FSC ook Europees goed past. Meer lees je bij [Interoperable Europe](https://interoperable-europe.ec.europa.eu/collection/api4dt/solution/federated-service-connectivity-core-specification).

## Design system

* **NLDD in Next.js:** we onderzoeken hoe we NLDD kunnen combineren met Next.js. Dat lukt nog niet helemaal, maar het onderzoek loopt door.
* **Van vaste tools naar HTML:** we merken dat PowerPoint en documenten ons minder vrijheid geven. Steeds vaker vertelt HTML ons verhaal beter. Daarom maakten we ook [de persona's en de klantreis in HTML](https://cx-moza.rijksapp.dev/).
* **Eén omgeving voor demo en proef:** we werken toe naar één omgeving waarin we zowel fictieve als echte koppelingen met diensten kunnen laten zien. Dat maakt het onderhoud eenvoudiger, terwijl we tegelijk de ontwikkelde diensten echt beproeven. Gebruikersonderzoeken en de demo's komen daarmee ook dichter bij elkaar te liggen.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Gebruikersonderzoek Berichtenbox - 13 & 14 juli
* MOZa Pulse - 16 juli
* Stuurgroep - 16 juli
* Regieteam - 6 augustus (mogelijk september vanwege de vakantieperiode)
* MOZa teamdag - 8 september (inclusief afsluiter met MOZa regieteam)

**Evenementen**

* [Hackathon Transparantie App](https://www.geonovum.nl/agenda/hackathon-transparantie-app-9-en-10-juli) - 9 & 10 juli
* [Common Ground Fieldlab](https://commonground.nl/events/view/1a31088b-5794-466c-8bf4-79be0a678eee/common-ground-fieldlab-14-en-15-september-2026) - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 1 juli 2026 (1 juli 2026)

## Algemeen

* **Ondernemer in zwaar weer:** we maakten kennis met de collega's die werken aan de levensgebeurtenis "de ondernemer in zwaar weer". Uit het werk dat daar is verzet komen herkenbare patronen. Gegevensuitwisseling is hier een groot thema, zodat ondernemers niet steeds dezelfde informatie hoeven aan te leveren als zij doorgaan naar het volgende loket. We verkennen de komende tijd hoe we kunnen samenwerken.
* **Start van werksessies:** in recente gesprekken met onze stakeholders merken we dat nog niet iedereen een volledig beeld heeft van wat MOZa doet. Er zijn veel begripsvragen, die we met platen en slides goed kunnen beantwoorden. Na de zomer organiseert MOZa daarom elke vier weken een werksessie op woensdagochtend. Zo stemmen we met partijen af over de stappen, uitdagingen en voortgang. Dit is een uitbreiding van de gesprekken die we de afgelopen tijd met de Belastingdienst hebben gevoerd, en waar we in ieder geval de KVK en RVO voor gaan uitnodigen. Wil je ook aanhaken? Neem dan even [contact](/contact/index.md) met ons op.
* **Dag van de toekomst geëvalueerd:** we blikten samen met [Digilab](https://digilab.overheid.nl/) terug op de [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk). We kijken terug op een geslaagde dag met mooie verbindingen en overheidsbrede samenwerking. Tegelijk is duidelijk dat "de oplossing" er nog niet ligt en dat we nog werk te verzetten hebben.
* **Team Lamarr van start:** rondom UX, gebruikersonderzoek, klantreizen en prototypes hebben we een team gevormd. Het team heet Lamarr, naar uitvinder Hedy Lamarr, die aan de basis stond van draadloze technologie zoals wifi en bluetooth. Het team werkt aan een eigen werkwijze: van concept, via goede UX, naar een frontend die we kunnen uitbouwen tot een volwaardige oplossing.
* **Werkwijze scherper beschrijven:** we werken aan een betere uitleg van onze werkwijze, die we nu nog "prototypend beleid maken" noemen. We willen goed onder woorden brengen wat we doen.
* **Versterking gezocht:** we hebben veel werk te verzetten en daarom zoeken we nieuwe collega's. Er staat nu een vacature open voor een Software/AI Engineer voor de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md). [Bekijk en deel de vacature — en bij interesse zien we je sollicitatie graag verschijnen.](https://www.linkedin.com/posts/rijksorganisatie-odi_vacature-alert-wil-jij-ai-inzetten-voor-activity-7477290347702759424-igIa)

## Gebruikersonderzoek

* **Inspirerende UX-dag:** op maandag 22 juni hadden we een UX-dag waarbij het team vooruit heeft gekeken. Een leuke en inspirerende dag met veel en diverse uitkomsten. De komende periode is er weer genoeg te doen.
* **Volgende onderzoek "Berichtenbox" gepland:** we werkten de planning uit voor het volgende gebruikersonderzoek van half tot eind augustus. We maken het [prototype](https://proef.moza.rijksapp.dev/moza/) hiervoor gereed en leggen gebruikers specifiek de Berichtenbox voor.
* **Invulling ondernemerspanel:** het is fijn om periodiek aan een vaste groep gebruikers vragen te kunnen stellen. Hiervoor gaan we aanhaken op het ondernemerspanel van EZK. Binnenkort doen we een eerste onderzoek om hier ervaring mee op te doen. Ook loopt er vanuit Logius een aanbesteding voor het werven van meer kandidaten voor gebruikersonderzoeken. Hierin worden ondernemers nu ook meegenomen.

## Notificatiedienst

* **MVP opzet NMC:** de focus van deze sprint ligt op een eerste versie van het Notificatie Management Component (NMC). We verwerkten meerdere review-rondes op de code, werkten de documentatie bij en zetten een eerste testversie op het [ZAD-cluster](https://zad.rijksapp.nl/).
* **Eerste contouren NMC-portaal:** we schetsten digitaal de eerste contouren van het self-serviceportaal voor het NMC. Het doel is zo snel mogelijk een versie te hebben die we als demo kunnen tonen.
* **Gesprekken met partijen:** we voerden veel gesprekken over de notificatiedienst. Met de Belastingdienst diepten we begrippen uit en deden we nieuwe inzichten op. Samen met de Belastingdienst zetten we in op een eerste MVP, waarbij nog niet alles hoeft te werken. Daarnaast hebben we geleerd dat nog niet alle stakeholders goed zijn meegenomen in wat we momenteel realiseren. De komende tijd besteden we hier samen met Obis aandacht aan.
* **Beheer en bewaking:** we werkten de health check- en alerting-service bij, zodat we de omgeving beter in de gaten kunnen houden.

## Profielservice

* **Verbeteringen in kaart:** we brengen functionele en technische verbeteringen van de [profielservice](/onderwerpen/profielservice/index.md) in kaart. De afgelopen sprint lag de nadruk vooral op de notificatiedienst, dus inhoudelijk was er op de profielservice weinig voortgang.
* **Waar draait de profielservice?:** we bepalen nog waar de profielservice komt te draaien. Hierover lopen verschillende gesprekken. Met de KVK verkennen we of het logischer is om functies die nu in de profielservice zitten, dichter tegen het handelsregister te plaatsen. Dit werken we de komende tijd verder uit.
* **Logboek Dataverwerkingen:** we werkten het Logboek Dataverwerkingen bij naar versie 1.0.0 van de standaard. Ook voegden we ondersteuning voor PostgreSQL toe. Zo maken we onze proefomgeving op het [ZAD-cluster](https://zad.rijksapp.nl/) efficiënter, want de eerdere versie op basis van ClickHouse vroeg veel geheugen.

## Architectuur

* **Beschrijvende architectuur:** we verwerkten de laatste feedback in het positioneringsdocument over de interactiedienstverlening van MijnOverheid. We boden een 0.9-versie van dit document en de ontwerpleidraad aan.

## Berichten / FBS

* **OpenFSC op ZAD:** we werken aan het uitrollen van [OpenFSC](https://fsc-standaard.nl/hoe-werkt-fsc/) op het [ZAD-cluster](https://zad.rijksapp.nl/). Zo kunnen onze projecten hiermee verbinden voor test- en acceptatiedoeleinden. We zetten het project op met de basis, de governance, testcertificaten en een directory. Het is nog even leren hoe het precies werkt, en dat lukt stap voor stap.
* **Aanpak toegelicht:** we begonnen aan een document dat onze aanpak en keuzes rond de [proefopstelling van het Federatief Berichtenstelsel](https://minbzk.github.io/moza-poc-fbs-berichtenbox/) toelicht.
* **Samenwerking verstevigd:** we hadden een constructief gesprek met Logius en BZK over het [Federatief Berichtenstelsel](/onderwerpen/berichten-fbs/index.md). We gaan de samenwerking verder verstevigen. Ook de NVWA toonde interesse in FBS, net als in de profiel- en notificatieservice.

## Digitale Assistent

* **Co-creatiedag:** we verdiepten ons een hele dag in de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md) tijdens een co-creatiedag bij de Belastingdienst in Utrecht. We begonnen met een "postcard from the future": wat zeggen ondernemers in 2028 over MOZa met de Digitale Assistent? Daaruit kwamen wensen als eenvoud, snelheid en richting geven. We brachten kansen, risico's en verbeterpunten in beeld en vertaalden de behoeften van ondernemers naar oplossingen.
* **Design sprint:** in een compacte design sprint verdiepten we de Digitale Assistent verder. De punten voor de expertreview pakken we nu op.
* **Kansen bij Logius:** in een workshop van Logius keken we hoe we de Digitale Assistent breder kunnen integreren en toepassen. Er liggen mooie kansen om hier nieuwe concepten voor te ontwikkelen.
* **Gebruikersonderzoek gepland:** we maakten een eerste planning voor gebruikersonderzoeken rond de Digitale Assistent.

## Regelhulpen, RegelRecht en machine-uitvoerbare wetgeving

* **Financieel CV:** we maakten de scope-documentatie voor Financieel CV, samen met het RVO Kenniscentrum Regelhulpen, en zetten dit in de [RegelRecht](https://regelrecht.rijks.app/)-editor. We kiezen er nu voor om ons op Financieel CV te richten en stopten voorlopig met de regelhulp voor de CSRD.
* **Kwaliteitsmanagement:** we maakten een plan om te starten met kwaliteitsmanagement.
* **Toekomst regelhulpen:** we spraken over de toekomst van de regelhulpen. De waarde van machine-uitvoerbare regelhulpen wordt gezien. Het is nu aan RVO om hier een plan voor te maken, maar waar het kan, helpen wij natuurlijk graag mee.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Teamoverleg - 1 juli
* Samenwerkdag met Logius - 1 juli
* Regieteam - 2 juli
* MOZa Pulse - 16 juli
* Stuurgroep - 16 juli

**Evenementen**

* [Omnichannel: ID-wallets in overheidsdienstverlening](https://www.gebruikercentraal.nl/agenda/online-bijeenkomst-omnichannel-id-wallets-in-overheidsdienstverlening/) - 2 juli (online)
* [Hackathon Transparantie App](https://www.geonovum.nl/agenda/hackathon-transparantie-app-9-en-10-juli) - 9 & 10 juli
* Common Ground Fieldlab - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 24 juni 2026 (24 juni 2026)

## Algemeen

* **MOZa Pulse:** tijdens deze editie gaven we een update over de notificatiedienst en lichtten we die toe aan de hand van de architectuurplaten. Daarnaast vertelden we over guerrillaonderzoek, deelden we onze eerste inzichten en lieten we de proefopstelling zien die we daarvoor gebruikten.
* **Terugblik Dag van de toekomst:** op 18 juni organiseerden we samen met [Digilab](https://digilab.overheid.nl/) de [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk). Een geslaagde dag met veel nieuwe verbindingen en het opdoen van nieuwe inzichten tijdens de workshops.
* **Ervaringen met Claude Code gedeeld:** we gaven een presentatie over onze ervaringen en geleerde lessen met Claude Code van de afgelopen maanden.
* **Site geschikt voor taalmodellen:** wie informatie bij publieke sites opvraagt, gebruikt daar steeds vaker AI-tools voor. Daarom maakten we de MOZa-site hier geschikt voor. De site serveert nu ook markdown en een `llms.txt`. Herkennen we een AI-agent, dan krijg je automatisch content die geoptimaliseerd is voor deze AI-agents. Dat scheelt weer wat tokens.
* **Programma-architect:** we voerden gesprekken voor een programma-architect voor Obis en MOZa. En met goed nieuws: per 1 juli start dit nieuwe teamlid.
* **Eerste PO-overleg:** het MOZa-team groeit en ondertussen werken er drie teams aan de diverse onderwerpen. De PO's hadden een eerste gezamenlijk overleg om afhankelijkheden en behoeftes te bespreken. Een mooie manier om te kijken hoe ze elkaar kunnen helpen richting de komende sprints.

## Gebruikersonderzoek

* **Ondernemersonderzoek bij de KVK:** onze gebruikersonderzoekers zaten een dag bij de KVK. Ze spraken ondernemers die daarvoor openstonden. Daarbij keken we ook mee hoe ondernemers zich inschreven bij de KVK. Zo kregen we mooie inzichten in hoe deze nieuwe ondernemers tegen informatie van de overheid aankijken.
* **Inzicht in opvragen van gegevens:** we rondden in de [proefopstelling](https://proef.moza.rijksapp.dev/moza/) de functie af waarmee we vastleggen welke partijen contactgegevens opvragen. Eerder maakten we hier een begin mee. Zo werken we toe naar inzicht voor gebruikers in welke partijen hun gegevens hebben opgevraagd.

## Profielservice

* **Richting productie:** we werken verder aan de profielservice volgens de acceptatievoorwaarden van Logius. We onderzochten tooling die Logius gebruikt en voerden die in. Zo bewaken we nu automatisch de codekwaliteit, waarmee we aansluiten bij de codeerstandaard die Logius hanteert.
* **DPIA:** we vulden de DPIA verder aan, vooral het deel over de gegevens. Ook stemden we af met het juridische team over de openstaande vragen.
* **Veilige foutmeldingen:** we voegden toe dat de profielservice bij een foutieve aanvraag (404) een nette foutmelding teruggeeft. Die toont geen gevoelige informatie meer. Dit stond eerder in review en is nu afgerond.
* **Code review met Claude Code:** we analyseerden de bevindingen uit de code review op de [profielservice](/onderwerpen/profielservice/index.md) en maakten hier issues van op de backlog. Deze punten werken we de komende tijd verder weg.
* **Logboek Dataverwerkingen:** Logius bracht versie 1.0.0 van de standaard voor het Logboek Dataverwerkingen uit. We bekeken wat dit voor ons softwarepakket betekent en maakten een begin met de aanpassingen.

## Notificatiedienst

* **De rol van het NMC:** het Notificatie Management Component (NMC) is de regisseur van het notificeren. Zelf verstuurt het geen berichten. Een dienstverlener biedt een notificatie aan via het decentrale Output Management Component (OMC). Het NMC pikt die op en regisseert het hele proces: het verzamelt de benodigde gegevens en bepaalt hoe en waar de notificatie heen moet. Het versturen geeft het door aan NotifyNL, dat de notificatie daadwerkelijk bezorgt. Daarna houdt het NMC bij wat er gebeurt en legt dit vast. Ook contactherstel valt onder zijn regie.
* **Opzet NMC:** we werkten aan de eerste opzet van het NMC. De architectuur van de oplossing bespraken we met elkaar en die krijgt steeds meer vorm. De eerste opzet is bijna klaar om te testen in de samenhang met NotifyNL.
* **Beslissingen vastgelegd:** we legden beslissingen over het NMC vast, zodat we ze kunnen delen en beoordelen. Ook werkten we de documentatie en het C4-model op componentniveau bij.
* **Contactherstel:** we werkten de sequence-diagrammen bij en voegden onder andere contactherstel toe als los element.
* **Samenwerking met Logius:** met twee teams werken we aan componenten van de notificatiedienst. Met elkaar bekijken we hoe we dit vorm kunnen geven. Zo starten we 1 juli een samenwerkdag voor deze teams.

## Architectuur

* **Beschrijvende architectuur:** we werkten verder aan het positioneringsdocument over de interactiedienstverlening van MijnOverheid.
* **Werkgroepen met Obis en update Bureau Architectuur:** afgelopen week hielden we de werkgroep Profiel & Notificeren en de werkgroep Architectuur & Standaarden. Deze gesprekken brengen ons op één lijn met de verschillende organisaties. Ook zien we beter waar we nog anders over denken. De opgedane inzichten en de voorgestelde architectuur bespraken we ook met Bureau Architectuur van BZK.
* **Eisen aan het autorisatiemodel:** de inzichten over het autorisatiemodel zijn breder bruikbaar. Ze sluiten aan op de update van de domeinarchitectuur voor het toegangsverleningsstelsel (TVS). Dit pakken we verder op met de collega's die hieraan werken.
* **Stakeholders meenemen:** we merken opnieuw hoe belangrijk het is om alle stakeholders mee te blijven nemen. Op sommige vlakken zijn we al verder dan betrokkenen weten. In de ene sessie dachten deelnemers opbouwend mee, in de andere stelden ze juist veel vragen bij de keuzes die we maakten. Daar geven we de komende tijd aandacht aan.

## Berichten / FBS

* **Proefopstelling op ZAD:** de [proefopstelling van het Federatief Berichtenstelsel](https://minbzk.github.io/moza-poc-fbs-berichtenbox/) draait nu op het [ZAD-cluster](https://zad.rijksapp.nl/) bij ODC-Noord. De omgevingen voor de uitvraag- en magazijnservices waren zichtbaar via hun eigen Swagger UI's: de uitvraagservice en de magazijnservice. Dit waren tijdelijke preview-omgevingen, die inmiddels niet meer bereikbaar zijn.
* **Stabielere tests:** we losten een bron van wisselvallige tests op, zodat onze testresultaten betrouwbaarder zijn.

## Machtigen en mandaten

* **Persona's en klantreizen:** we werkten verder aan de persona's en klantreizen voor authenticatie, autorisatie, machtigen en mandaten. Zo gaan we goed voorbereid de werksessie van 30 juni in. Dit sluit aan op de actie uit het [plan voor fase 4](/documenten/rapportages/plan-moza-fase-4/).

## Design system

* **Experimenteren met NLDD:** we onderzochten onder andere NLDD in combinatie met server-side rendering.
* **Componenten NLDS:** met (RHC-)NLDS kijken we verder naar de inzet van componenten voor het ondernemersportaal.
* **Persona's en klantreis visueel:** we maakten met NLDD een eerste versie van persona-cards en een tijdlijn voor de klantreis. Deze gebruikten we in de workshop op de Dag van de toekomst.

## Digitale Assistent

* **Demo verbeterd:** we verbeterden de demo van de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md) met een notificatie, een formulier in de chat en functionaliteit die een zaakdossier aanmaakt zodra je een rapportage instuurt.
* **Op weg naar MVP:** we hebben een lijst opgesteld met to-do's voor de MVP en de bèta.

## Regelhulpen, RegelRecht en machine-uitvoerbare wetgeving

* **Validatie Financieel CV:** we draaiden de nieuwe validatieskills van [RegelRecht](https://regelrecht.rijks.app/) over de branch voor Financieel CV. Hieruit kwamen verbeteringen en materiaal voor de workshop voort.
* **Documentatie:** we beschreven de scope en de samenhang met de stelsels.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Kennismaking levensgebeurtenissen KVK (Utrecht) - 25 juni
* Werksessie machtigen en mandaten - 30 juni
* Teamoverleg - 1 juli
* Samenwerkdag met Logius - 1 juli
* Regieteam - 2 juli
* MOZa Pulse - 16 juli
* Stuurgroep - 16 juli

**Evenementen**

* [Samen versnellen met AI: de overheid van morgen begint nu](https://www.aanmelder.nl/174738) - 25 juni
* [Dag van de Digitale Toegankelijkheid](https://dagvandedigitaletoegankelijkheid.nl/) - 28 juni
* [Omnichannel: ID-wallets in overheidsdienstverlening](https://www.gebruikercentraal.nl/agenda/online-bijeenkomst-omnichannel-id-wallets-in-overheidsdienstverlening/) - 2 juli
* [Hackathon Transparantie App](https://www.geonovum.nl/agenda/hackathon-transparantie-app-9-en-10-juli) - 9 & 10 juli
* Common Ground Fieldlab - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 17 juni 2026 (17 juni 2026)

## Algemeen

* **Dag van de toekomst: ondernemer centraal:** we hebben de laatste hand gelegd aan het programma en de workshops. Vanuit verschillende rollen beschrijven we levensgebeurtenissen waar een zakelijke gebruiker tegenaan loopt. Met elkaar gaan we aan de slag om dit als klantreis inclusief oplossingsrichtingen uit te werken. We organiseren deze dag samen met [Digilab](https://digilab.overheid.nl/).
* **Logius PI event:** op 10 en 11 juni waren we bij het PI event van Logius. We maakten met alle betrokkenen een goede werkverdeling voor de notificatiedienst en de [profielservice](/onderwerpen/profielservice/index.md). Ook ondertekenden we samen met Logius de MOZa-intentieverklaring, een mooie stap in onze samenwerking. Ook vanuit gebruikersonderzoek en UX stemden we het nodige af. Onder andere over de mogelijkheid om te wisselen tussen burger en onderneming.
* **Juridisch meedenken:** hoe we het precies gaan doen, dat gaan we binnenkort bespreken. Maar we gaan kijken hoe we het juridische team al eerder aan kunnen haken in ons proces. Bijvoorbeeld door nieuwe prototypes die we hebben onderzocht, van tijd tot tijd met elkaar te bespreken.
* **Veilig met AI:** als team schreven we onze ervaringen met AI op. Ook onderzochten we veiligere manieren om ontwikkelomgevingen te draaien waar we Claude Code met maximale kracht in kunnen zetten. Onze huidige aanpak is nog niet veilig genoeg, maar wordt wel steeds veiliger. Tot die tijd blijven er restricties in stand.
* **Levensgebeurtenis "ondernemer in zwaar weer":** we spraken met de KVK over ondernemers in zwaar weer. De KVK werkt hier in opdracht van BZK aan. Binnenkort hebben we een vervolg en gaan we onderzoeken hoe we kunnen samenwerken.

## Gebruikersonderzoek

* **Prototype doorontwikkeld:** we werkten verder aan het [prototype](https://proef.moza.rijksapp.dev/moza/) voor de volgende ronde aan onderzoeken.
* **Onderzoek bij de KVK:** ons geplande gebruikersonderzoek bij de KVK is verschoven naar volgende week. Samen met KVK Rotterdam gaan we onder andere het gesprek aan met ondernemers die zich net hebben ingeschreven. Een mooie manier om ondernemers te spreken over wat hun verwachtingen zijn en te toetsen of onze ideeën daarbij aansluiten.
* **Inzicht in opvragen van gegevens:** in het prototype maakten we een begin met een functie waarmee gebruikers kunnen zien welke overheidspartijen welke gegevens hebben opgevraagd.
* **Wisselen tussen burger en ondernemer:** op het Logius PI event spraken we over de samenhang met het burgerdomein en over hoe je soepel wisselt tussen het burger- en het zakelijke domein. Eerder gemaakte schetsen hiervoor nemen we mee in de komende onderzoeken.

## Profielservice

* **Richting productie:** we verwerkten de concept-acceptatievoorwaarden van Logius, patchten beveiligingsbevindingen, schreven beheerdocumentatie over database en deployment, en voegden een vaste codeerstandaard toe.
* **Kwaliteit en privacy:** we voegden contracttesten toe, zodat we ons automatisch aan de gemaakte API-afspraken blijven houden. Ook kwam er een veld "te verwijderen op" in het datamodel. Daarnaast tonen foutmeldingen geen gevoelige informatie meer.
* **Logboek Dataverwerkingen:** we werkten aan een stabiele release van het Logboek Dataverwerkingen.
* **Code review met Claude Code:** we lieten een code review op de profielservice uitvoeren met Claude Code. De bevindingen analyseren we volgende week.
* **Juridisch proces:** we bereiden het juridische proces voor dat we per 1 juli willen starten. Daarvoor zorgen we dat de DPIA en het beleidskompas op orde staan.

## Notificatiedienst

* **Start van het NMC:** we trapten het Notificatie Management Component (NMC) af. We bepaalden waar de documentatie staat, wat we eerst uitzoeken en wat juist (nog) niet. We brachten de eerste focus aan. Het doel: een notificatie laten lopen van de dienstverlener (OMC) naar de NMC, die deze met behulp van NotifyNL per e-mail verstuurt.
* **NotifyNL:** we vatten de NotifyNL-specificatie samen, zodat duidelijk is hoe je deze kunt benaderen.
* **Implementatieplan:** we vulden het implementatieplan verder in, met de bouwstenen en de verdeling van het werk.
* **Samen met Logius:** we delen met Logius hetzelfde beeld van de notificatiedienst en hebben het werk voor de korte termijn verdeeld. Zo werken we samen aan het gestelde doel.

## Architectuur

* **Architectuursessies:** we bereiden sessies voor over de beschrijvende architectuur en het positioneringsdocument.
* **Profielservice en andere bronnen:** we denken na over hoe de profielservice zich verhoudt tot het ontsluiten van andere bronnen, zoals de BRP en het handelsregister van de KVK. Voorlopig laten we dit via de profielservice lopen, maar we zijn er nog niet over uit.
* **Bereikbaarheidsservice:** er kwam de vraag of de bereikbaarheidsservice onderdeel kan worden van de profielservice. Dit zoeken we uit.
* **Mijn Taken:** we maakten een korte analyse van Mijn Taken, als vertrekpunt voor de verdere verkenning in het ondernemersdomein.

## Berichten / FBS

* **Bouwstenen afgerond:** we rondden de bouwstenen van de [proefopstelling](https://minbzk.github.io/moza-poc-fbs-berichtenbox/) van het [Federatief Berichtenstelsel](/onderwerpen/berichten-fbs/index.md) af in een eindsprint. We verwerkten onder andere de overgang van de aanmeldservice naar de sessiecache en losten losse verbeterpunten op.
* **C4-model uitgebreid:** we werkten het C4-model bij en breidden het uit met een berichtenmagazijn dat een organisatie zelf beheert.
* **Demo in voorbereiding:** in de refinement bepaalden we welke use cases en flows we in de demo van de proefopstelling willen laten zien. Wordt vervolgd...
* **Afstemming met BZK:** we stemmen met BZK af omdat FBS een onderwerp is waar al veel werk op is verzet. We willen daarop voortbouwen en er tegelijk met een frisse blik naar kunnen kijken.

## Machtigen en mandaten

* **Workshops in voorbereiding:** we maakten een eerste opzet voor workshops over authenticatie, autorisatie, machtigen en mandaten. Dit sluit aan op de actie uit het [plan voor fase 4](/documenten/rapportages/plan-moza-fase-4/). Hierin definiëren we onze persona's en schetsen we samen de klantreizen. De eerste sessie met het MOZa-team staat op dinsdag 30 juni. Een vervolg met een breder publiek plannen we nog. Als je interesse hebt, stuur dan een e-mail naar moza@minbzk.nl.

## Design system

* **Eén lijn in look-and-feel:** we bekijken welke omgevingen we nodig hebben voor demo's, proeven en ontwikkeling. We houden de look-and-feel en functionaliteit consistent.
* **Experimenteren met NLDD:** we maakten een analyse van onze design-systemen: het NL Design System (NLDS), MOx en NLDD. We gaan experimenteren met NLDD en werken parallel verder met (RHC-)NLDS, zodat we goed aansluiten op de ontwikkelstraat van Logius.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* MOZa Pulse - 18 juni
* Werkgroep standaarden en architectuur (Obis / MOZa) - 18 juni
* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* UX-onderzoeksdag - 22 juni
* Verdieping met de Belastingdienst over notificeren en contactherstel - 24 juni
* Kennismaking levensgebeurtenissen KVK (Utrecht) - 25 juni
* Werksessie machtigen en mandaten - 30 juni
* Regieteam - 2 juli
* Stuurgroep - 16 juli

**Evenementen**

* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* [Bijeenkomst Netwerk van Datastelsels](https://realisatieibds.nl/groups/view/0056c9ef-5c2e-44f9-a998-e735f1e9ccaa/federatief-datastelsel/events/view/1a08b8c2-65d7-4da9-9114-36a8d51bbb6a/bijeenkomst-netwerk-van-datastelsels-23-juni) - 23 juni
* [Samen versnellen met AI: de overheid van morgen begint nu](https://www.aanmelder.nl/174738) - 25 juni
* [Dag van de Digitale Toegankelijkheid](https://dagvandedigitaletoegankelijkheid.nl/) - 28 juni
* [Omnichannel: ID-wallets in overheidsdienstverlening](https://www.gebruikercentraal.nl/agenda/online-bijeenkomst-omnichannel-id-wallets-in-overheidsdienstverlening/) - 2 juli (online)
* Common Ground Fieldlab - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 10 juni 2026 (10 juni 2026)

## Algemeen

* **Onderwerppagina's bijgewerkt:** we werkten verschillende onderwerppagina's bij of voegden deze toe. Het gaat om de pagina's over de [Profielservice](/onderwerpen/profielservice/index.md), [Berichten / FBS](/onderwerpen/berichten-fbs/index.md) en de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md).
* **Dag van de toekomst: ondernemer centraal:** we zijn druk met de voorbereidingen voor [18 juni](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk). De workshops staan en er zijn leuke sprekers. Je kunt je nog aanmelden. We organiseren deze dag samen met [Digilab](https://digilab.overheid.nl/).
* **Business wallets:** verschillende collega's bezochten het [Symposium European Business Wallet](https://ecp.nl/agenda/symposium-de-european-business-wallet-het-fundament-voor-een-concurrerend-digitaal-bedrijfsleven/). De rode draad: over een aantal jaar verloopt veel dienstverlening via de wallet, en bijna elke klantreis begint met inloggen. We vinden dit een belangrijk onderwerp en kijken hoe we dit mee gaan nemen in de ontwikkeling als onderdeel van de [proeftuin](/onderwerpen/proeftuin/index.md). Naar aanleiding van het VNG MijnServices Festival is er ook contact geweest met de Gemeente Nijmegen.
* **Werkgroep MijnZaken/MijnTaken:** we haakten aan bij deze werkgroep van Obis / MOZa om op de hoogte te blijven van de ontwikkelingen. Binnenkort start ook de verkenning vanuit MOZa gericht op het ondernemersdomein. Met het werk dat al wordt verzet, hebben we een mooi vertrekpunt.
* **ODI:** we praatten het directieteam van [Rijksorganisatie ODI](https://www.rijksorganisatieodi.nl/) bij over MOZa en onze werkwijze. Daarbij ook een hulpvraag neergelegd hoe we op een efficiënte manier van het netwerk van ODI gebruik kunnen maken. Daar gaan we nog opvolging aan geven via het ODI-thema netwerksamenwerking.
* **Inwerken met AI:** onze open en transparante manier van werken helpt nu nieuwe collega's snel op weg. Een nieuwe collega kan namelijk met Claude als "buddy" in korte tijd veel context over MOZa en onze omgeving krijgen, juist omdat onze informatie open en goed vindbaar is. Zo ontdekken we dat we ook ongepland nieuwe manieren van inwerken verkennen.

## Gebruikersonderzoek

* **Prototype aangescherpt:** we verwerkten inzichten uit eerder onderzoek in het [prototype](https://github.com/MinBZK/moza-poc) en scherpten de content aan voor de volgende doelgroep die we onderzoeken. De wijzigingen volgen elkaar momenteel snel op en houden we daarom bij in een [changelog](https://github.com/MinBZK/moza-poc/blob/main/CHANGELOG.md).
* **Team gebruikersonderzoek en UX:** het team rond UX en gebruikersonderzoek krijgt steeds meer vorm en heeft vanaf nu ook een eigen product owner. Zo bouwen we aan een uniforme ervaring voor onze gebruikers, zoeken we samenwerking en aansluiting, en delen we inzichten met de andere teams.

## Profielservice

* **Over de profielservice:** de pagina over de [profielservice](/onderwerpen/profielservice/index.md) staat nu echt met de meest recente versie online.
* **DPIA in de maak:** we werken aan de DPIA voor de profielservice en hebben deze van een update voorzien. We brengen de informatie bij elkaar en houden die begrijpelijk voor een breder publiek.
* **Richting productie:** we kijken waar we de profielservice verder kunnen professionaliseren, met het oog op productie. Hierover vindt ook afstemming met Logius plaats, zodat we met elkaar een steeds beter beeld krijgen van de kaders en voorwaarden.

## Notificatiedienst

* **Beschrijving aangescherpt:** we scherpen de beschrijving van de notificatiedienst verder aan. Dit is nog werk in uitvoering en wordt binnenkort gepubliceerd.
* **Logius PI event:** samen met Logius bereiden we het PI event van 10 en 11 juni voor, met onder andere aandacht voor het plan voor de livegang en de postverzending, zodat we contactherstel kunnen organiseren.

## Architectuur

* **Beschrijvende architectuur:** we werkten deze week verder aan de beschrijvende architectuur rondom alles wat met berichten te maken heeft.
* **Kennismaking Digipoort:** in een kennismaking met Logius over Digipoort zagen we één toepassing die lijkt op wat wij willen: gegevens ophalen bij de Belastingdienst om een aangifte in te vullen. Of dit patroon herbruikbaar is, is nog niet duidelijk.

## Berichten / FBS

* **Pagina over Berichten:** de pagina over [Berichten](/onderwerpen/berichten-fbs/index.md) staat online.
* **Documentatie:** we hebben ons C4-model over onze implementatie van het [Federatief Berichtenstelsel](https://minbzk.github.io/moza-poc-fbs-berichtenbox/) bijgewerkt. Daarnaast is er een visiedocument in ontwikkeling waar we ook naar gaan kijken.
* **Techniek:** we troffen voorbereidingen voor een aanmeldservice, maakten de berichtensessiecache lichter (in-process in plaats van via REST) en breidden onze CI/CD-tests uit met checks op codekwaliteit en coverage.
* **Webinar:** we woonden het webinar Standaarden in het Federatief Datastelsel bij.

## Authenticatie en autorisatie

* **Aftrap:** met een aantal collega's hadden we een aftrap over authenticatie en autorisatie. We bespraken wat er al is en spraken af wie wat verder oppakt. Dit raakt aan de actie mandaten en machtigen uit het [plan voor fase 4](/documenten/rapportages/plan-moza-fase-4/).
* **Vanuit de klantreis:** we starten met een dagdeel waarin we vanuit een klantreis met persona's nadenken over oplossingsrichtingen, op basis van bestaande informatie. Daarna willen we hier samen met onze stakeholders aan gaan werken.

## Digitale Assistent

* **Pagina over Digitale Assistent:** ook de pagina over [Digitale Assistent](/onderwerpen/digitale-assistent/index.md) staat online.
* **Verhuizing afgerond:** we rondden de verhuizing van de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md) naar een [eigen omgeving](https://github.com/MinBZK/moza-poc-digitale-assistent) af. De assistent is nog steeds geïntegreerd in de proefopstelling, maar kan nu makkelijker worden doorontwikkeld.
* **AI-Verordening:** we liepen de beslishulp van de AI-Verordening door voor twee scenario's: in gebruik en in ontwikkeling.
* **Dag van de toekomst:** we bereiden de demo voor 18 juni voor.

## Regelhulpen, RegelRecht en machine-uitvoerbare wetgeving

* **Demo BZK:** we presenteerden de samenwerking tussen RegelRecht en MOZa aan collega's van BZK en "stiekem" ook JenV met leuke positieve reacties.
* **Vervolg Regelhulpen:** met RVO en BZK bespraken we het vervolg van de Regelhulpen. Dit sluit aan op de pilots die we nu al doen.
* **Toekomstbeeld Regelhulpen:** samen met RVO hebben we open gesproken over de eerste stappen richting een toekomstbeeld. Een regelhulp kan een wet of regeling makkelijker uitleggen, als aanvulling op [RegelRecht](https://regelrecht.rijks.app/). Dit verkennen we verder.
* **Financieel CV:** we bereidden de volgende sessie met het RVO-team voor Financieel CV voor.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Logius PI planning - 10 & 11 juni
* Regieteam - 11 juni (tijdens het Logius PI event)
* MOZa Pulse - 18 juni
* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* UX-onderzoeksdag - 22 juni
* Stuurgroep - 16 juli

**Evenementen**

* [GovTech Day](https://www.digitaleoverheid.nl/evenementen/govtech-day/) - 11 juni
* Dag van de Publieke Dienstverlening - 17 juni
* [Overheid360°](https://www.digitaleoverheid.nl/evenementen/overheid360/) (Jaarbeurs Utrecht) - 17 juni
* Developer.overheid.nl meetup - 17 juni
* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* Werkgroep standaarden en architectuur (Obis) - 18 juni
* [Bijeenkomst Netwerk van Datastelsels](https://realisatieibds.nl/groups/view/0056c9ef-5c2e-44f9-a998-e735f1e9ccaa/federatief-datastelsel/events/view/1a08b8c2-65d7-4da9-9114-36a8d51bbb6a/bijeenkomst-netwerk-van-datastelsels-23-juni) - 23 juni
* [Samen versnellen met AI: de overheid van morgen begint nu](https://www.aanmelder.nl/174738) - 25 juni
* [Dag van de Digitale Toegankelijkheid](https://dagvandedigitaletoegankelijkheid.nl/) - 28 juni
* [Omnichannel: ID-wallets in overheidsdienstverlening](https://www.gebruikercentraal.nl/agenda/online-bijeenkomst-omnichannel-id-wallets-in-overheidsdienstverlening/) - 2 juli (online)
* Common Ground Fieldlab - 14 & 15 september
* Business Wallet B2G - 22 of 23 september
* [Europe goes Once-Only: the Netherlands](https://www.digitaleoverheid.nl/evenementen/europe-goes-once-only-the-netherlands/) - 24 & 25 september
* [IBDS-Stelseldag 2027](https://www.digitaleoverheid.nl/evenementen/ibds-stelseldag-2027/) - 3 februari 2027

## MOZa Weekly 3 juni 2026 (3 juni 2026)

## Algemeen

* **MOZa event:** vergeet je niet om je aan te melden voor de [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) op 18 juni vanaf 12:00.
* **[VNG MijnServices Festival](https://www.digitaleoverheid.nl/evenementen/mijnservices-festival/):** op 28 mei stonden we op de vloer met presentaties en demo's. We voerden veel goede gesprekken, onder andere over (business) wallets en het delen van gegevens van nutsbedrijven met de overheid. De komende tijd gaan we deze gesprekken opvolgen en verdiepingen plannen.
* **Routekaartoverleg MijnOverheid:** op basis van het [statusrapport fase 3](/documenten/rapportages/statusrapport-moza-fase-3/) gaven we een update over wat we hebben gedaan. Daaraan koppelden we een samenvatting van onze [plannen voor fase 4](/documenten/rapportages/plan-moza-fase-4/). Zo delen we de plannen voor MijnOverheid breder. Stap voor stap brengen we zaken bij elkaar.
* **Nieuwe collega's:** er zijn nieuwe collega's gestart. Van harte welkom! Een mooi moment om onze [onboarding-flow te testen en aan te scherpen](/handboek/jouw-start/).

## Gebruikersonderzoek

* **Iets nieuws:** in onze werkwijze zetten wij de [ondernemer centraal](/handboek/werkwijze/principes/index.md#ondernemer-centraal). Daarom deze week iets nieuws: ons eerste guerrilla-onderzoek. We gaan naar een locatie en gaan daar in gesprek met ondernemers en burgers. Zo horen we hoe zij tegen onderwerpen aankijken.
* **Guerrilla-onderzoek in Den Haag:** we spraken negen mensen "in het wild" bij een kringloopwinkel. We wilden weten of mensen last hebben van een doorverwijzing naar MOZa bij het inloggen vanaf overheid.nl en mijn.overheid.nl. Het antwoord: nee, daar hebben ze geen last van.
* **Volgende stappen:** volgende week leggen we een vergelijkbare vraag voor aan ondernemers bij de KVK in Rotterdam. Ook willen we op 18 juni ondernemers spreken in Arnhem.
* **Prototype uitgebreid:** voor dit onderzoek bouwden we de inlogflow "Uniform inloggen" van Figma om naar een HTML-prototype. We voegden ook een [fictieve inlogflow](https://proef.moza.rijksapp.dev/inloggen/) en [een fictieve mailbox](https://proef.moza.rijksapp.dev/mailbox/) toe aan het prototype.
* **Browser-extensie:** we maakten een browser-extensie waarmee we links op bestaande pagina's kunnen aanpassen of toevoegen. Zo kunnen we bijvoorbeeld op een pagina van de KVK of RVO een verwijzing naar MOZa tonen en testen hoe mensen daarop reageren.
* **MijnKVK:** in een gesprek met het UX-team van MijnKVK verkenden we wat we voor elkaar kunnen betekenen. We houden elkaar voorlopig op de hoogte van de ontwikkelingen.

## Profielservice

* **Sprint afgerond:** we rondden alle issues uit de sprint af. In de nieuwe sprint ligt de focus op het verder verbeteren van de [profielservice](/onderwerpen/profielservice/index.md) en het onderzoeken van inlogmethoden.
* **Pentest in voorbereiding:** we bereiden een pentest voor en die staat met potlood ingetekend voor eind september. We willen daarmee in elk geval de profielservice en het Notificatie Management Component laten toetsen.
* **Hosting in de Logius Project Cloud:** in een sessie met Logius bespraken we het hosten van de profielservice in de Logius Project Cloud. Daaruit kwamen randvoorwaarden en acceptatiecriteria, die we nu omzetten in concrete stories.
* **Documentatie aangevuld:** we werkten [de documentatie](https://docs.mijnoverheidzakelijk.nl/workspace/documentation/Profiel%20Service) bij over database-migraties, over authenticatie en autorisatie op de Logius Project Cloud, en over ons secret-management.
* **LDV-validatie:** we maakten een validatie voor het Logboek Dataverwerkingen met behulp van AI-skills. Deze staat klaar om na te kijken.
* **Demo Gemeente Amsterdam:** we ondersteunden Gemeente Amsterdam bij hun demo op het VNG MijnServices Festival.

## Notificatiedienst

* **Notificatie Management Component (NMC):** het NMC krijgt een eigen plek binnen de notificatiedienst. De eisen leggen we vast op een centrale requirements-pagina, zodat nieuwe wensen daar terechtkomen. Deze publiceren we binnenkort op de MOZa-site.
* **Implementatieplan:** samen met Obis vullen we het implementatieplan voor de notificatiedienst verder in. Dit is ook de voorbereiding op de Logius PI planning van 10 en 11 juni. We brengen in kaart bij wie we tijd moeten reserveren.
* **Afstemming:** we voerden veel gesprekken met Logius en de Belastingdienst. Het beeld dat wij hebben bij de profielservice en notificatiedienst sluit goed aan bij dat van de Belastingdienst.

## Architectuur

* **Beschrijvende architectuur:** we werken aan de beschrijvende architectuur in een positioneringsdocument. We bespraken een tussenversie en verwerken de aanscherpingen. We voegen een hoofdstuk toe over de interactiediensten uit het cluster Bereikbaarheid: profiel-registratie, autorisatie-verlening, notificatie-management en berichten-administratie.

## Berichten / FBS

* **Stakeholdermapping en presentatie:** we werkten aan een stakeholdermapping en aan een presentatie. Daarmee nemen we belanghebbenden mee in wat we doen en enthousiasmeren we hen.
* **Federatief, geen centrale lijst:** in gesprekken werd bevestigd dat je in een federatief stelsel liever geen centrale lijst hebt. Dat past goed bij onze aanpak.
* **Magazijn-resolver:** we hebben een magazijn-resolver toegevoegd aan de [proefopstelling van het Federatief Berichtenstelsel](https://minbzk.github.io/moza-poc-fbs-berichtenbox/). Deze resolver bepaalt uit welke berichtenmagazijnen iemand berichten mag en wil ontvangen. Dit doen we op basis van de profielservice. Machtigingen hebben we hier nog niet in meegenomen.
* **Uitvraagservice:** de berichten-uitvraagservice is klaar. Die pakken we als volgende op.
* **Tekst op de site:** we werken aan de tekst voor de pagina over [Berichten](/onderwerpen/berichten-fbs/index.md).

## Digitale Assistent

* **Eigen omgeving:** we verhuizen de [Digitale Assistent](/onderwerpen/digitale-assistent/index.md) uit de gezamenlijke proefopstelling naar een [eigen repository](https://github.com/MinBZK/moza-poc-digitale-assistent). We schonen meteen op en voegden een verantwoording over ons AI-gebruik toe.
* **Demo op het festival:** de demo op het VNG MijnServices Festival ging goed.

## Machine-uitvoerbare wetgeving

* **[RegelRecht](https://regelrecht.rijks.app/) en validatie:** met het validatieteam zetten we een volgende stap in de methode om machine-leesbare wetten te maken en te valideren. We bepaalden samen wat en wie we daarvoor nodig hebben.
* **Financieel CV:** we zetten de wetten voor Financieel CV in de RegelRecht-editor. Volgende week werken we verder met het team van RVO.
* **Pionieren met RegelRecht:** op 1 juni hadden we met BZK een sessie over pionieren met RegelRecht. Ook JenV haakte enthousiast aan.

## Agenda

💡 Wist je dat we (bijna) elke maandag samenwerken op het Beatrixpark in Den Haag? Wil je een keer aanhaken, dan ben je van harte welkom.

**MOZa**

* Logius PI planning - 10 & 11 juni
* Regieteam - 11 juni (tijdens het Logius PI event)
* Dag van de Publieke Dienstverlening - 17 juni - MOZa verzorgt een workshop
* MOZa Pulse - 18 juni
* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* UX-onderzoeksdag - 22 juni
* Stuurgroep - 16 juli

**Evenementen**

* Webinar Standaarden in het Federatief Datastelsel - 4 juni
* [OneGov AI Hackathon Series](https://www.digitaleoverheid.nl/evenementen/onegov-ai-hackathon-series/) - 4 & 5 juni
* [Common Ground Congres](https://commonground.nl/events/view/919890aa-dd01-488c-bbba-8d6c197e9b0f/common-ground-congres-8-juni-2026) - 8 juni
* [FOST Amsterdam](https://apidays.global/fost-events/amsterdam) - 9 & 10 juni (developer.overheid.nl verzorgt een API- en Open Source-track)
* [GovTech Day](https://www.digitaleoverheid.nl/evenementen/govtech-day/) - 11 juni
* [Overheid360°](https://www.digitaleoverheid.nl/evenementen/overheid360/) (Jaarbeurs Utrecht) - 17 juni
* Developer.overheid.nl meetup - 17 juni
* [Dag van de toekomst: ondernemer centraal](https://digilab.pleio.nl/groups/view/c182ef44-4cf1-4912-9afa-da3e8b509f32/evenementen-algemeen/events/view/969b45cd-7057-4251-a949-32214fe43663/dag-van-de-toekomst-ondernemer-centraal-en-regeldruk) - 18 juni - MOZa samen met [Digilab](https://digilab.overheid.nl/)
* Werkgroep standaarden en architectuur (Obis) - 18 juni
* [Samen versnellen met AI: de overheid van morgen begint nu](https://www.aanmelder.nl/174738) - 25 juni
* [Dag van de Digitale Toegankelijkheid](https://dagvandedigitaletoegankelijkheid.nl/) - 28 juni
* Common Ground Fieldlab - 14 & 15 september
* Business Wallet B2G - 22 of 23 september

---
Gegenereerd op 2026-09-07 | https://mijnoverheidzakelijk.nl/