Kring Techniek

De kring Techniek is een van de drie kringen binnen de Nuts community, naast Toepassingen en Gezamenlijk Belang. Wij zijn verantwoordelijk voor de community-brede en toepassings-overstijgende technische kaders en visie

Kring Techniek Informatie

De kring Techniek is een van de drie kringen binnen de Nuts community, naast Toepassingen en Gezamenlijk Belang. Wij zijn verantwoordelijk voor de community-brede en toepassings-overstijgende technische kaders en visie. Die stellen we vast op basis van consent.

Deze pagina beschrijft wie we zijn en waar je ons vindt. Wil je weten waar we op dit moment aan werken, kijk dan op Waar we mee bezig zijn.

Domein en mandaat

Onze verantwoordelijkheden, kort samengevat:

  1. We beheren, ontwikkelen en dragen de technische kaders uit, ter bevordering van kwaliteit, herbruikbaarheid en eenduidigheid van open source specificaties en implementaties voor het landelijke GIS.
  2. We zorgen voor kaders voor beheer en ontwikkeling van ondersteunde implementaties, en dragen er zorg voor dat die taken belegd zijn.
  3. We ondersteunen de community met tools en activiteiten voor samenwerking (wiki, website, code-repository, project-boards, Slack, hackathons, community meetings) en met kennis.
  4. We participeren in het landelijke GIS en kiezen samen aan welke landelijke projecten we deelnemen, in lijn met het meerjarenplan en het Nuts Manifest.

Het volledige mandaat staat hier: Mandaat Kring Techniek

Wat we dit jaar binnen dat mandaat prioriteren staat in het Jaarplan 2026/2027, vastgesteld op 5 juni 2026.

Beleid en uitvoering

De kring stelt de kaders en de technische visie vast, en maakt de keuzes over prioriteit, volgordelijkheid en deelname aan projecten. De uitvoering doet de kring niet allemaal zelf, maar belegt zij: bij werkgroepen met een concrete opdracht, bij rollen zoals de producteigenaar van de nuts-node, en bij teams en projecten die binnen onze kaders werken.

Ontbreekt er een kader, of is er onduidelijkheid over een uitgangspunt, dan kun je dat bij de kring brengen via #kring-techniek-aanspreekpunt.

Rollen

Rol Wie
Coördinator Steven van der Vegt
Afgevaardigde naar de Nuts Raad Edwin de Wit
Gespreksleider Karin Vosters
Notulist en logboekhouder Roland Groen
Producteigenaar nuts-node Rein Krul

Vergaderingen

De kring vergadert elke vier weken online, op woensdag van 10:00 tot 11:30. De data staan ook in de Nuts kalender.

Datum
21 september 2026
21 oktober 2026
18 november 2026
16 december 2026
13 januari 2027
10 februari 2027
10 maart 2027
7 april 2027
2 juni 2027
30 juni 2027

De agenda wordt aan het begin van elke vergadering vastgesteld. Wil je een onderwerp agenderen, laat dat weten aan de coördinator; het komt dan op de voorraadagenda in het logboek.

Subkringen en werkgroepen

Op dit moment heeft de kring geen subkringen. Er zijn twee werkgroepen.

Werkgroep Technische Convergentie. Een gedeelde werkgroep met de kring Toepassingen, die de technische convergentie tussen de zorgtoepassingen moet versnellen en de afstemming tussen de toepassingsverantwoordelijken en deze kring borgt. Beide kringen geven een eigen, aanvullende opdracht aan dezelfde werkgroep en vaardigen zelf deelnemers af. De werkgroep is op 27 augustus 2026 voor het eerst bijeengekomen; de instelling en de opdracht vanuit deze kring zijn nog niet bekrachtigd. Zie de pagina voor wat dat betekent voor de afvaardiging.

Werkgroep Architectuur. Nog in oprichting. Krijgt de opdracht om openstaande architectuurpunten voor te bereiden voor besluitvorming in de kring, om de samenhang tussen de Nuts-specifieke voorzieningen en de landelijke generieke functies te bewaken, en om een voorstel uit te werken voor het domein van een eventuele subkring Architectuur.

Een werkgroep is de lichtere vorm: er hoort geen eigen domein, kringleider en afgevaardigde bij. Groeit het werk uit tot een eigen domein, dan kan een werkgroep overgaan in een subkring.

Werkgroepen krijgen een concrete opdracht van de kring en werken daarbinnen zelfstandig. Deelnemers zijn mede-auteurs van het resultaat, niet alleen geconsulteerde partijen. Deelname vraagt geen lidmaatschap van de hoofdkring. Het resultaat dient als basis voor consent-besluitvorming in de kring.

Documentatie die onder ons domein valt

Naast dit boek beheren we onder meer:

Waar je ons vindt

Waarvoor Waar
Een vraag aan de kring #kring-techniek-aanspreekpunt
Coördinatie en governance van de kring #kring-techniek-pub
Technische en supportvragen over de software #development
Releases van de nuts-node #releases
Werkgroep Technische Convergentie #wg-technische-convergentie
Logboek (agenda's, besluiten, voorraadagenda) Logboek Kring Techniek
Documenten Drive-map Kring Techniek
Bijeenkomsten Nuts kalender

Nog geen Slack-account? Via nuts.nl/community kun je je aanmelden voor de Nuts Slack workspace.

Meedoen

Er zijn drie manieren om betrokken te raken.

Een vraag stellen of iets agenderen. Stel je vraag in #kring-techniek-aanspreekpunt. Wil je een onderwerp op de agenda van de kring, laat dat weten aan de coördinator; het komt dan op de voorraadagenda in het logboek. De agenda wordt aan het begin van elke vergadering vastgesteld, dus agendering is geen garantie op behandeling in de eerstvolgende bijeenkomst.

Meedoen in een werkgroep. Dit vraagt geen lidmaatschap van de hoofdkring en is de meest laagdrempelige manier om inhoudelijk bij te dragen.

Deelnemer worden van de kring. Je kunt jezelf voordragen of worden voorgedragen. De kring besluit hierover met consent.

Besluitvorming

De kring besluit op basis van consent: een voorstel is aangenomen tenzij er een overwegend bezwaar is. Een bezwaar gaat over het doel en het werk van de kring en hoeft niet uitgebreid onderbouwd te zijn.

Structuur- en beleidsbesluiten, zoals het instellen van een werkgroep of het vaststellen van een kader, gaan via consent in de kringvergadering. Urgente of operationele zaken kunnen tussentijds als tijdelijke maatregel worden genomen, met een bezwaartermijn, en worden in de eerstvolgende vergadering bekrachtigd.

De Nuts Raad corrigeert onze besluiten alleen als er overwegend bezwaar is vanuit de kringen Toepassingen of Gezamenlijk Belang.

Waar we mee bezig zijn

Dit is het overzicht van alles wat op dit moment onder het mandaat van de kring Techniek valt. Inclusief wat aan ons gevraagd is en nog niet belegd is, want ook dat willen we zichtbaar maken.

Zie Kring Techniek voor het mandaat, de rollen en hoe je meedoet.

Statussen

Status Betekenis
Loopt Er wordt aan gewerkt en er is een aanspreekpunt
In voorbereiding Belegd, maar nog niet begonnen of wacht op een besluit
Gevraagd, nog niet belegd Aan ons gevraagd, niemand pakt het op
Gepauzeerd Bewust stilgelegd, met een reden
Afgerond Klaar, blijft staan als naslag

Doorlopend werk

Onderwerp Status Waar
Beheer en doorontwikkeling nuts-node Loopt #development
Community-tooling en samenwerkingsmiddelen Loopt #kring-techniek-aanspreekpunt
Technische ondersteuning aan gebruikers en implementaties Loopt #development
Reviews van specificaties en reacties op consultaties Loopt #kring-techniek-aanspreekpunt
PDCA-cyclus: jaarplan, begroting, jaarverslag, input Nuts Raad Loopt #kring-techniek-pub
COT: ontwikkeling van het knooppunt en de bijbehorende keuzes Niet beschreven #gf-cot

Van dit doorlopende werk zijn de nuts-node en de community-tooling als opdracht beschreven. Het COT is het grootste gat: daar worden inhoudelijke keuzes gemaakt die onder ons mandaat vallen, zonder dat die keuzes via de kring lopen. Dit vraagt een voorstel vanuit de coördinatoren, op basis van het mandaat en het vervolgplan, met daarin alle activiteiten.

Projecten

Onderwerp Status Waar
LSP x Nuts Loopt #lspxnuts
Generieke Functies: knooppunt, COT en CCT Loopt #gf-cot
Migratie naar Nuts v6 en did:web Loopt #kring-techniek-aanspreekpunt
Verwijzen naar het Landelijk afsprakenstelsel Loopt #kring-techniek-aanspreekpunt
Werkgroep Technische Convergentie In voorbereiding, eerste bijeenkomst gehouden #wg-technische-convergentie
Werkgroep Architectuur In voorbereiding #kring-techniek-pub
Vernieuwing van de technische documentatie In voorbereiding #gf-cot
Hosting van de GF-testomgeving In voorbereiding #kring-techniek-pub
Referentie-ontwerpen per communicatiepatroon In voorbereiding #kring-techniek-pub
Impactanalyse technisch profiel eOverdracht In voorbereiding #kring-toepassingen
Aanbesteding GF-pilots Landelijk Dekkend Netwerk In voorbereiding #gf-leveranciers
QTSP-verkenning (federatief, eIDAS2-conform) In voorbereiding #kring-techniek-pub
Verhuizing van de wiki van Google Cloud Gevraagd, nog niet belegd #kring-techniek-aanspreekpunt

Verzoeken die we oppakken

Vragen van buiten die we in een opdracht hebben omgezet of aan het omzetten zijn. Per verzoek staat op de eigen pagina wat er gevraagd is, wat de opdracht is en wat de kring nog moet besluiten. Afgeronde verzoeken blijven staan, met het resultaat op de pagina.

Onderwerp Status Waar
Harmonisatie TA Notified Pull Loopt #kring-techniek-pub
Reactie op de VWS-memo Harmonisatie van Authenticatie en Autorisatie Loopt #kring-techniek-pub
GISA-consultatie 2026 Loopt #kring-techniek-pub
PKIOverheid G4-transitie (per 12 november 2026) In voorbereiding #kring-techniek-pub
Nuts x MedMij: PoC-voorstellen Gevraagd, nog niet belegd #kring-gezamenlijk-belang
KPMG-nulmeting Landelijk Dekkend Netwerk Afgerond #kring-techniek-pub

Deelname aan externe gremia

Gremium Status Namens ons
Twiin werkgroep harmonisatie TA Notified Pull Loopt Steven van der Vegt en Dirk Geurs
VWS Design Authority, generieke functies Loopt Roland Groen (adressering)
iWLZ groeipad interoperabiliteit Loopt Steven van der Vegt
LAS werkgroep verwijzen naar landelijke afspraken In voorbereiding nog te bepalen
Twiin werkgroep TA Pull, namens LSP x Nuts In voorbereiding nog te bepalen
GIS-A: redactieteam, stuurgroep, transitiearchitectuur Gepauzeerd niemand
Twiin werkpakket Veilig Netwerk en de pilots Gepauzeerd niemand
iWLZ technisch afstemmingsoverleg Gevraagd, nog niet belegd niemand

Gevraagd, nog niet belegd

Dit zijn vragen die bij de kring zijn neergelegd en waar op dit moment niemand aan werkt. Wil je er een oppakken of erover meedenken, laat het weten in #kring-techniek-aanspreekpunt.

Onderwerp Van wie Sinds
Afstemming met het Actieprogramma iWLZ Actieprogramma iWLZ juni 2026
Kennismaking met Nictiz over de eOverdracht-testomgeving met Nuts Nictiz juni 2026
Profiel voor het meten van Nuts-gebruik, samen met KIK-V ActiZ-evaluatie, aanbeveling 9 februari 2026
Opzetten van ondersteuning voor leveranciers en dienstverleners ActiZ-evaluatie, aanbeveling 7 februari 2026
Uitwerken van de transitiearchitectuur Nuts binnen GIS-A GIS-A doorlopend
Twiin najaarsrelease 1.6 Twiin via Sergej van Middendorp juli 2026
Technische reflectie op het SAZ-memo over stoppen met eigen Nuts-ontwikkeling kring Gezamenlijk Belang juli 2026
Positiebepaling rond de EDI-wallet en business wallets onder eIDAS2 kring Gezamenlijk Belang juli 2026
Toekomst van het Slack Pro-abonnement, dat rond half november afloopt kring Gezamenlijk Belang augustus 2026
Memo Provenance signing in GFA, aangeboden ter review Roland Groen augustus 2026
CumuluZ hergebruik-quickscan CumuluZ via Sergej van Middendorp augustus 2026

Twee eerdere punten van deze lijst zijn inmiddels belegd. Aanbeveling 4 uit de ActiZ-evaluatie, over herbruikbare technische bouwblokken, ligt bij de Werkgroep Technische Convergentie en de Werkgroep Architectuur. De inventarisatie van het v5-gebruik en de migratiedocumentatie horen bij Migratie naar Nuts v6 en did:web.

Werk van andere kringen waar wij een rol in hebben

Onderwerp Onze rol Waar
Zorginzage 2026 en 360 graden cliëntbeeld Review van de specificatie, gevraagd consent op v1.0 en het faciliteren van een consultatie voor v1.1 #360-graden-clientbeeld
Website en communicatie Technische ondersteuning en beheer van de omgeving, het domein ligt bij de kring Gezamenlijk Belang #website
Mitz x Nuts Technisch-inhoudelijke keuzes, onder meer over de MC-connector #kring-gezamenlijk-belang

Projecten

Projecten

LSP x Nuts

Status: loopt Waar: #lspxnuts

Wat het is

LSP x Nuts realiseert een koppeling tussen het Landelijk Schakelpunt (AORTA) en het Nuts-netwerk, zodat partijen aan beide kanten gegevens bij elkaar kunnen opvragen zonder dat elke deelnemer zich aan het andere stelsel hoeft aan te passen.

Het traject kent twee fasen. Fase 1 maakt het mogelijk dat Nuts-partijen gegevens kunnen raadplegen bij het LSP. Fase 2 maakt het mogelijk dat Nuts-partijen ook zelf als bron kunnen fungeren, zodat het LSP gegevens bij hen kan opvragen. In fase 2 worden de generieke functies gebruikt en wordt het nuts-knooppunt ingezet waar dat kan.

Het project heeft een eigen coördinatie, waarin naast Nuts onder meer VZVZ en VWS deelnemen. Het is daarmee geen project van de kring Techniek, maar de technische inhoud valt wel onder ons mandaat.

Waarom dit onder ons mandaat valt

Wij stellen de architectuur en de specificaties op, en zorgen dat de implementatie in de nuts-node beschikbaar is. Dat raakt zowel onze technische kaders als het beheer van onze eigen standaarden en de nuts-node. Besluiten over de koers van het project zelf liggen bij de projectcoördinatie.

Wat er nu speelt

Bewegende delen en TODO's:

Er loopt nogal wat, dit een lijstje om overzicht te houden.

Wie erbij betrokken zijn

Rol Wie
Architectuur, PSA en solution design Steven van der Vegt, Dirk Geurs
Implementatie in de nuts-node Rein Krul
Technische afstemming pilots wekelijks, dinsdagmiddag

Aan VZVZ-kant en vanuit VWS zijn eigen contactpersonen betrokken; dat loopt via de projectcoördinatie.

Documenten en repositories

De PSA en het solution design staan op de SharePoint van VZVZ en zijn nog niet openbaar.

Hoe haak je aan

Voor vragen over deelname aan de pilots of over de technische vereisten: stel ze in #lspxnuts. Voor vragen over hoe dit zich verhoudt tot de technische kaders van Nuts: #kring-techniek-aanspreekpunt.

Projecten

Verwijzen naar het Landelijk afsprakenstelsel

Status: loopt Waar: #kring-techniek-aanspreekpunt

Wat het is

Het Landelijk afsprakenstelsel (LAS) moet de plek worden waar generieke landelijke afspraken staan. Andere afsprakenstelsels verwijzen daar dan naar in plaats van eigen varianten te maken. De werkgroep Verwijzen naar Landelijk afsprakenstelsel heeft richtlijnen opgesteld voor hoe dat verwijzen moet werken. Nuts is een van de deelnemende afsprakenstelsels.

Wij hebben hier twee losse maar verbonden opdrachten.

Opdracht 1: deelname aan de werkgroep. Sergej van Middendorp nam tot juli 2026 namens Nuts deel en heeft dat overgedragen aan de kring Techniek. De werkgroep werkt aan het vervolg op de richtlijnen en organiseert een PoCathon om te toetsen of het verwijsmechanisme werkt. Het gaat daar uitsluitend om het mechanisme (permalinks, metadata, register), niet om de inhoud van de afspraken.

Opdracht 2: beproeving van de richtlijn. In ons eigen overleg is besloten dat de kring Techniek de richtlijn zou beproeven, met de afspraak Veilig netwerk als object om naar te verwijzen. Voorwaarde was dat Twiin eerst duidelijk zou maken waar de richtlijn staat, wat de status is en waar de afspraak staat. Dat is inmiddels geregeld. De beproeving zelf is nog niet uitgevoerd.

De twee opdrachten gebruiken dezelfde richtlijn maar hebben een ander doel. Opdracht 1 toetst het mechanisme gezamenlijk, opdracht 2 toetst het vanuit ons eigen stelsel.

Waarom dit onder ons mandaat valt

Verwijzen naar externe afspraken raakt hoe wij onze eigen specificaties publiceren en versioneren: permalinks, metadata, en notificatie bij breaking changes. Dat is documentatie- en beheerwerk aan onze eigen standaarden en valt daarmee onder ons mandaat.

Wat wij wel en niet kunnen toetsen is belangrijk om vooraf vast te leggen. Wij kunnen vaststellen of een verwijzing technisch werkt: of het object vindbaar is, een stabiele permalink heeft, versioneerbaar is en zelfstandig leesbaar. Wij kunnen niet vaststellen of dat waarnaar wij verwijzen logisch en passend is. De afspraak Veilig netwerk stelt eisen aan de bedrijfsvoering van zorgaanbieders en hun leveranciers, en dat is niet iets waar wij als Nuts eisen over willen of kunnen stellen.

Twee onderdelen vallen daarmee buiten ons mandaat:

Hoe het speelveld in elkaar zit

Wat er nu speelt

Eerste analyse

Dit zijn inzichten uit het lezen van de richtlijnen en het PvE en uit navraag bij Twiin. De beproeving en de huiswerkopdracht zijn nog niet uitgevoerd.

Documenten

Wat Waar
Richtlijnen Verwijzen naar landelijke afspraken in Twiin, v0.2, juni 2026 twiin.nl
PvE Netwerkbeveiliging Twiin Deelnemer (TA150), normatief afsprakenstelsel.twiin.nl
PvE Netwerkbeveiliging Twiin Deelnemer (TC150D), prepublicatie consultatie.twiin.nl
Landelijk afsprakenstelsel, algemene informatie datavoorgezondheid.nl
Uitnodiging PoCathon, Kris van Hamelen (VWS), 3 augustus 2026 per e-mail, 29 oktober 2026 in Den Haag

De richtlijnen v0.2 bevatten in bijlage 1 een begrippenmodel en in bijlage 2 een metamodel voor de meta-informatie van een afspraak.

Wie erbij betrokken zijn

Rol Wie
Overdracht deelname werkgroep Sergej van Middendorp
Coördinatie en analyse Steven van der Vegt
Deelname werkgroep en PoCathon nog te bepalen

Contactpersoon bij Twiin is Ursula Letschert. Voor vragen over de status van de richtlijnen en over eventuele verplichting: Ageeth Wahle (VWS).

Hoe haak je aan

Voor vragen over deze opdrachten of over deelname aan de werkgroep en de PoCathon: #kring-techniek-aanspreekpunt.

Projecten

Werkgroep Technische Convergentie

Status: in voorbereiding, eerste bijeenkomst gehouden Waar: #wg-technische-convergentie en #kring-techniek-pub

De werkgroep kwam op 27 augustus 2026 voor het eerst bijeen. De instelling is nog niet in beide kringen bekrachtigd en de opdracht vanuit kring Techniek staat nog niet vast. Zie Wat nog niet is vastgesteld.

Het leidende document is het Voorstel Werkgroep Technische Convergentie: het gezamenlijke besluit, de opdrachten van beide kringen, de resultaten en de grenzen. Agenda's, aanwezigen en acties staan in het logboek van de werkgroep. Deze pagina geeft de context en wat deze kring te besluiten heeft.

Wat het is

Kring Toepassingen en Kring Techniek stellen samen één Werkgroep Technische Convergentie in. Beide kringen geven de werkgroep een eigen, aanvullende opdracht en vaardigen zelf deelnemers af. De opdrachten zijn niet aan elkaar gericht maar aan dezelfde werkgroep; de werkgroep werkt als één team, en de herkomst van een deelnemer bepaalt niet wie welk deel van het werk doet.

De werkgroep komt in de plaats van het zorgtoepassingsontwerpersoverleg. Ons jaarplan beschrijft dezelfde werkvorm: een structuur waarlangs signalen van toepassingsontwerpers en leveranciers bij de kring binnenkomen en waarlangs wij de technische richting teruggeven. Het gaat dus om hetzelfde gat, en daarom wordt het één werkgroep in plaats van twee.

Het is een werkgroep, geen overleg. Een werkgroep heeft een opdracht, levert een resultaat op en vraagt tijd van deelnemers tussen de bijeenkomsten door.

Relevantie voor Nuts

De migratie naar did:web en de convergentie naar gedeelde bouwblokken lopen per zorgtoepassing, en het eigenaarschap daarvan ligt bij de toepassingen. Onze rol is faciliterend: technische input en context leveren, niet de migratiepaden van andere kringen bezitten. Wat tot nu toe ontbreekt is een vaste plek waar die twee kanten elkaar treffen. Daardoor komen ondersteuningsvragen ad hoc binnen en blijven kaderkeuzes liggen omdat niemand ze voorbereidt.

Voor deze kring is het belang concreet: hier komt in beeld welke gedeelde bouwblokken de toepassingen nodig hebben, wordt getoetst of de referentie-ontwerpen daarop aansluiten, en wordt zichtbaar welke vraagstukken om een kaderkeuze in de kring vragen.

Wat de kringen samen besluiten

Het voorstel vraagt beide kringen de werkgroep in te stellen, de gezamenlijke opdracht en grenzen te onderschrijven, elk deelnemers af te vaardigen, Edwin de Wit en Roland Groen te vragen de start en procesbegeleiding te organiseren, en na drie maanden te evalueren.

Het besluit treedt in werking zodra beide kringen het gezamenlijke deel hebben bekrachtigd. Een kring kan haar eigen opdracht aanpassen; wijzigingen aan het gezamenlijke doel, de grenzen of de werkwijze vragen instemming van beide kringen.

Wat wij de werkgroep vragen

Kring Techniek vraagt de werkgroep om:

  1. Per zorgtoepassing het technische beeld op te bouwen dat nodig is om te kunnen ondersteunen bij de migratie naar did:web en de landelijke generieke functies: welke technische stap er aan de orde is en waar die op vastloopt.
  2. Als mede-auteur te werken aan de referentie-ontwerpen per communicatiepatroon, en die toe te passen bij het ontwerp van een nieuwe toepassing of een nieuwe versie daarvan.
  3. Technische ontwikkelingen, releases en standaarden vanuit de kring Techniek te vertalen naar gevolgen en acties voor de zorgtoepassingen.
  4. Bij de kring Techniek neer te leggen wat de toepassingen tegenhoudt en niet in een referentie-ontwerp is op te lossen: ondersteuningsvragen die capaciteit vragen, en vraagstukken die een kaderkeuze nodig hebben, met het probleem, de mogelijke richtingen en hun voor- en nadelen.

De referentie-ontwerpen zijn de vorm waarin de kring Techniek de gedeelde bouwblokken oplevert: een uitgewerkt ontwerp per communicatiepatroon waarop een toepassing zich profileert. De Werkgroep Architectuur bepaalt welke bouwblokken een referentie-ontwerp kent en hoe die samenhangen, en beheert het geheel; de invulling per bouwblok gebeurt samen met deze werkgroep. Welke bouwblokken nodig zijn en met welke prioriteit, volgt uit de behoefte van de zorgtoepassingen.

Blijkt een referentie-ontwerp in de praktijk niet uitvoerbaar, binnen de beschikbare tijd of met de bestaande implementaties, dan is dat aanleiding om het ontwerp aan te passen en niet om ervan af te wijken. Komen beide werkgroepen er samen niet uit, dan gaat het als kaderkeuze naar de kring Techniek.

Deze kring vaardigt zelf deelnemers af, bij voorkeur via de Werkgroep Architectuur. Is die werkgroep bij de start nog niet actief, dan wijst de kring tijdelijke vertegenwoordigers aan.

Kring Toepassingen vaardigt per zorgtoepassing een inhoudelijk verantwoordelijke af en vraagt de werkgroep vooral om zicht op de technische ontwikkelingen, afhankelijkheden en migratievoortgang per toepassing, en om kansen voor harmonisatie uit te werken tot vervolgstappen.

De werkgroep bepaalt zelf haar agenda, werkwijze en interne taakverdeling binnen de opdracht. Zij heeft geen eigen domein en neemt geen besluiten namens de kringen over technische kaders, standaarden, prioriteiten van toepassingen, de inzet van mensen en middelen, of de governance van afzonderlijk gefinancierde trajecten.

Wat nog niet is vastgesteld

De werkgroep is gestart voordat de instelling en de opdracht rond waren. Dat kan, maar het heeft gevolgen die hier expliciet staan.

Afvaardiging. Je bent afgevaardigd als je kring met consent heeft ingestemd met naam, rol, tijdsbeslag en termijn. Dan spreek je namens die kring en koppel je daar terug. Zonder dat besluit draag je bij op persoonlijke titel. Voor geen enkele deelnemer is nu een afvaardigingsbesluit vastgelegd: de lijst uit het voorstel van 5 augustus 2026 was voorlopig, en de vraag was of mensen konden aansluiten, niet of ze een rol aanvaardden.

Borging. De werkgroep kan van start, maar stel de afvaardiging snel vast, want zonder is er geen borging dat besluiten worden gedragen en uitgevoerd. Dit is een taak voor de eerste bijeenkomsten.

Mandaat en subkringen. De subkringen binnen kring Toepassingen bestaan nog niet. Deelnemers ontlenen hun mandaat dus aan de kring zelf, of ze hebben het niet.

Openstaande vragen:

  1. Welke deelnemers bevestigt de eigen kring, met welke rol, welk tijdsbeslag en welke termijn?
  2. Welke toepassingen zijn nu niet met mandaat vertegenwoordigd, en wat is er nodig om dat te regelen?
  3. Wat is de status van wat de werkgroep oplevert zolang die vertegenwoordiging ontbreekt: een voorstel aan de kringen, of een afspraak tussen toepassingen?
  4. Welk tijdsbeslag verwacht de werkgroep tussen de bijeenkomsten door, en is dat met werkgevers afgestemd?

Planning

Wanneer Wat
19 augustus 2026 Instemming in het operationeel overleg van kring Toepassingen
27 augustus 2026 Eerste bijeenkomst, daarna elke twee weken
15 september 2026 Bekrachtiging en afvaardiging in kring Toepassingen
21 september 2026 Bekrachtiging, opdracht en afvaardiging in kring Techniek
Eind november 2026 Evaluatie van opdracht, samenstelling en werkwijze

Te besluiten

  1. Geeft de kring consent op het gezamenlijke besluit en op de opdracht vanuit deze kring, zoals opgenomen in het voorstel?
  2. Wie vaardigt de kring af, met welke rol, welk tijdsbeslag en welke termijn, en loopt dat via de Werkgroep Architectuur of via tijdelijke vertegenwoordigers?
  3. Maakt de werkgroep in haar opleveringen zichtbaar welke toepassingen niet met mandaat vertegenwoordigd waren?

Samenhang met andere trajecten

Bronnen

Wat Waar
Voorstel Werkgroep Technische Convergentie, leidend document Google Docs
Logboek van de werkgroep, agenda's en acties Google Docs
Logboek Kring Techniek, vergaderingen 20 en 27 augustus 2026 Google Docs
Voorstel van Edwin de Wit voor het omvormen van het zorgtoepassingsontwerpersoverleg, 5 augustus 2026 Slack
Zorgtoepassingenkompas, beoogd als centraal statusoverzicht, nu in draft zt-kompas.vercel.app

Wie erbij betrokken zijn

Rol Wie
Start, agenda en procesbegeleiding Edwin de Wit en Roland Groen
Afvaardiging vanuit Kring Techniek nog te bepalen, bij voorkeur via de Werkgroep Architectuur
Afvaardiging vanuit Kring Toepassingen per zorgtoepassing een inhoudelijk verantwoordelijke, nog te bevestigen

Aan de eerste bijeenkomst namen elf mensen deel; de aanwezigen staan in het logboek. Zij dragen bij op persoonlijke titel totdat hun kring de afvaardiging bevestigt.

Hoe haak je aan

Wil je meedenken over de convergentie tussen zorgtoepassingen of over de migratie van een specifieke toepassing, sluit aan in #wg-technische-convergentie of laat het weten in #kring-techniek-aanspreekpunt.

Projecten

Werkgroep Architectuur

Status: in voorbereiding Waar: #kring-techniek-pub

Wat het is

Er ligt een reeks architectuurvraagstukken die nu stuk voor stuk in de hoofdkring landen en de agenda vullen: de deelname aan de VWS Design Authority en de structuur daaromheen, de reactie op het A&A-advies, de PKIOverheid G4-transitie, de Twiin-werkgroep LAS, de transitiearchitectuur binnen GIS-A, en de samenhang van de technische documentatie.

Er is eerder gesproken over een subkring Architectuur. Daar hoort een uitgewerkt domein bij met een coördinator en een afgevaardigde, en dat ligt er nog niet. Een werkgroep is de lichtere vorm die het mandaat hiervoor biedt: een concrete opdracht, zelfstandig werken binnen die opdracht, resultaat terug naar de kring.

Relevantie voor Nuts

De kring stelt de technische kaders en de visie vast, maar de vraagstukken die daarom vragen komen nu ongefilterd op de agenda. Daardoor kost besluitvorming veel vergadertijd en blijven onderwerpen liggen die voorbereiding nodig hebben. Een werkgroep die deze punten besluitrijp maakt, geeft de kring de ruimte om te besluiten in plaats van uit te zoeken.

Daarnaast is er een structurele plek nodig voor architectuurwerk dat over meerdere trajecten heen loopt: de verhouding tussen de Nuts-specifieke voorzieningen en de landelijke generieke functies is niet één project maar een doorlopende vraag.

Voorgestelde opdracht

De kring stelt een werkgroep Architectuur in, met als doel de samenhang in de Nuts-architectuur te bewaken en architectuurvraagstukken besluitrijp te maken voor de kring.

Scope. De werkgroep:

Buiten scope: besluiten over technische kaders en over deelname aan externe gremia. Die blijven bij de kring. Ook het eigenaarschap van de migratiepaden per toepassing valt hier niet onder; dat ligt bij de toepassingen zelf.

Resultaat. Besluitrijpe voorstellen, met per vraagstuk het probleem, de oplossingsrichtingen en hun voor- en nadelen. Daarnaast een voorstel voor het domein van een subkring Architectuur.

Belegging. Roland Groen, Dirk Geurs, Rein Krul en Steven van der Vegt.

Werkwijze. De werkgroep werkt zelfstandig binnen deze opdracht en rapporteert in elke kringvergadering. De inhoudelijke ondersteuning aan de Werkgroep Technische Convergentie loopt via de deelnemer die deze kring daarheen afvaardigt.

Referentie-ontwerpen

Wie een toepassing op Nuts bouwt, staat voor een reeks technische keuzes die per toepassing opnieuw worden gemaakt: hoe autorisatie wordt vastgesteld, hoe de vindplaats van gegevens wordt bepaald, hoe de gebruiker wordt geauthenticeerd, en hoe partijen elkaar vertrouwen. Dat leidt tot divergentie tussen toepassingen, tot herhaald ontwerpwerk, en tot ontwerpen die pas laat op consistentie met de kaders worden getoetst. Het geldt voor nieuwe toepassingen net zo goed als voor bestaande die naar did:web migreren.

Referentie-ontwerpen vullen dat gat: een uitgewerkt ontwerp dat een toepassing als vertrekpunt neemt en waarop zij zich profileert. Ze maken de technische kaders concreet en toepasbaar, en zijn daarmee de invulling van de herbruikbare technische bouwblokken waar de ActiZ-evaluatie om vraagt.

Eén generiek referentie-ontwerp is te grof, omdat de communicatiepatronen te veel van elkaar verschillen. Het onderscheid loopt langs twee assen: gericht of ongericht beschikbaar stellen, en de wijze waarop de gegevens worden opgehaald en gelokaliseerd.

Patroon Voorbeeldtoepassing
Gericht beschikbaar stellen, pull, mogelijk met notificatie zonder workflow Huisartsinzage, al op did:web
Ongericht beschikbaar stellen, pull met lokalisatie of discovery de inzagetoepassingen
Indexed pull, waarbij de lokalisatie van de gegevens via een index loopt nader te bepalen
Notified pull met workflow eOverdracht
Taakgebaseerde autorisatie ANW

Maatwerk per toepassing blijft daarna nodig en ligt bij de toepassing zelf.

Verhouding tot de generieke zorginzage-specificatie. Die specificatie is in opzet hetzelfde: een generiek vertrekpunt waarop inzagetoepassingen zich profileren. Zij is echter buiten de kring tot stand gekomen en het beheer ervan is niet belegd. Overweging is die specificatie onder het beheer van deze kring te brengen, als referentie-ontwerp voor het patroon ongericht beschikbaar stellen. Dat is een apart besluit dat de kring los moet nemen; het blokkeert dit onderdeel niet. Wordt het besluit niet genomen, dan blijft er overlap tussen de zorginzage-specificatie en de referentie-ontwerpen bestaan.

Wie doet wat. Deze werkgroep maakt en beheert de referentie-ontwerpen. De Werkgroep Technische Convergentie geeft input op de referenties en past ze toe op de concrete zorgtoepassingen. De subkringen per toepassing implementeren ze en rapporteren blokkades terug aan de Werkgroep Technische Convergentie.

Wat er voor de werkgroep klaarligt

Onderwerp Waar het staat
Referentie-ontwerpen per communicatiepatroon deze pagina
Gedeelde bouwblokken en hun verhouding tot de generieke functies Werkgroep Technische Convergentie
Overkoepelende v6-vraagstukken, waaronder discovery service en GF-adressering jaarplan, openstaande kaderkeuze
VWS Design Authority en de structuur daaromheen afvaardiging belegd bij Roland Groen
Reactie op het A&A-advies van VWS eigen pagina
PKIOverheid G4-transitie eigen pagina
Twiin najaarsrelease 1.6 en de werkgroep LAS eigen pagina
Transitiearchitectuur Nuts binnen GIS-A jaarplan, nog niet belegd
Samenhang van de technische documentatie architectuurvraag onder het procesvoorstel van het COT, komt in stap 4 bij de kring terug

Planning

Wanneer Wat
Voor de Twiin-consultatie van 5 oktober Referentie voor notified pull gereed, als onderdeel van de impactanalyse eOverdracht

Te besluiten

  1. Geeft de kring consent op het instellen van de werkgroep en op de opdracht zoals hierboven beschreven?
  2. Klopt de samenstelling, en is er ruimte voor deelnemers van buiten de kring?
  3. Wie vaardigt de werkgroep af naar de Werkgroep Technische Convergentie?
  4. Brengt de kring de generieke zorginzage-specificatie onder haar beheer, als referentie-ontwerp?

Samenhang met andere trajecten

Bronnen

Wat Waar
Agendapunt B, kringvergadering 20 augustus 2026 Logboek Kring Techniek
Mandaat Kring Techniek, over werkgroepen en hun opdracht Google Docs

Wie erbij betrokken zijn

Rol Wie
Beoogde deelnemers Roland Groen, Dirk Geurs, Rein Krul, Steven van der Vegt
Afvaardiging naar de Werkgroep Technische Convergentie nog te bepalen

Hoe haak je aan

Deelname aan een werkgroep vraagt geen lidmaatschap van de kring. Wil je meedoen aan het architectuurwerk, laat het weten in #kring-techniek-aanspreekpunt.

Projecten

Migratie naar Nuts v6 en did:web

Status: loopt Waar: #kring-techniek-aanspreekpunt en #development

Wat het is

Onder "de v6-migratie" gaan twee verschillende dingen schuil.

De node-upgrade van v5 naar v6 is een deployment-wijziging: een SQL-store, een domeinnaam, gewijzigde poorten en TLS-terminatie. v6 is backwards compatible op API's en features, dus een toepassing die op did:nuts draait blijft werken op een v6-node.

De toepassingsmigratie van did:nuts naar did:web is een herontwerp van de toepassing: did:web en did:x509, OpenID4VCI voor de uitgifte van credentials, OID4VP als basis voor het token request, een discovery service of de GF-adressering in plaats van het gRPC-netwerk, en autorisatie op basis van de eigen administratie in plaats van de NutsAuthorizationCredential.

Die twee worden vaak als één ding besproken. Dat heeft een risico: het maakt de node-upgrade afhankelijk van besluitvorming die daar niet voor nodig is. Deze pagina houdt ze uit elkaar en beschrijft wat de kring in beide doet.

Relevantie voor Nuts

did:nuts en het gRPC-netwerk zijn deprecated en moeten uit. Het netwerk vervult op dit moment vier functies: het distribueren van publieke credentials voor adressering en zoeken, het uitwisselen van private credentials tussen partijen, het publiceren van intrekkingen, en het publiceren van DID-documenten met de bijbehorende sleutelrotatie. Voor elk daarvan moet iets in de plaats komen voordat het netwerk uit kan.

Zolang dat niet gebeurt, stapelen de kosten zich op. De resourcebehoefte van het netwerk blijft stijgen, er moet een dubbele stack in stand worden gehouden, en nieuwe leveranciers willen niet meer op did:nuts bouwen terwijl bestaande toepassingen er nog op draaien. Dat maakt aansluiten bij een bestaande toepassing moeilijker, precies waar groei zou moeten ontstaan.

De drie stappen

Stap Wat Waar het ligt
1 Node-upgrade naar v6 Kring Techniek, rechtstreeks met leveranciers en node-beheerders
2 Ontwerp van de nieuwe toepassingsversie Werkgroep Technische Convergentie, met de Werkgroep Architectuur
3 Implementatie van dat ontwerp Kring Toepassingen en de leveranciers

Stap 1 en 2 kunnen parallel: ontwerpen vraagt geen v6-node. Stap 2 vraagt wel een referentie-ontwerp voor het betreffende communicatiepatroon; zolang dat er niet is, kan een toepassing wel starten maar loopt zij het risico keuzes te maken die later afwijken. Stap 3 vereist dat stap 1 klaar is en dat er een ontwerp uit stap 2 ligt.

Daarmee is de node-upgrade de kritieke voorwaarde voor het geheel, en die kan nu al vooruit zonder dat één toepassing een besluit hoeft te nemen.

Wat er nu speelt

Opdracht 1: node-upgrade naar v6

Doel. Alle deelnemers draaien op een v6-node, zodat het uitfaseren van did:nuts en het gRPC-netwerk niet op de deployment vastloopt.

Scope. Inventarisatie van wie nog op v5 draait en wat hen tegenhoudt; documentatie op het niveau van een beheerder in plaats van een ontwikkelaar; en ondersteuning per leverancier bij de upgrade zelf.

Buiten scope: het omzetten van de toepassing, en het beheer van individuele nodes bij deelnemers.

Resultaat. Een beeld van het resterende v5-gebruik, bijgewerkte migratiedocumentatie, en deelnemers die de upgrade kunnen uitvoeren.

Belegging. Het producteigenaarschap van de nuts-node, zie Beheer en doorontwikkeling nuts-node.

Werkwijze. Rechtstreeks met de leveranciers en node-beheerders, zoals dat bij KIK-V is gedaan via een eigen kanaal en een gezamenlijke doorloop van de bevindingen. Dit vraagt geen tussenkomst van een toepassing.

Opdracht 2: ontwerp van de nieuwe toepassingsversie

Doel. Elke toepassing heeft een uitgewerkt ontwerp voor de overgang naar did:web, gebaseerd op een referentie-ontwerp en niet op een eigen interpretatie.

Scope. Per toepassing in beeld brengen welke technische stap aan de orde is en waar die op vastloopt; de referentie-ontwerpen per communicatiepatroon toepassen op de toepassing; en de vraagstukken die om een kaderkeuze vragen terugbrengen naar de kring.

Buiten scope: de implementatie zelf, en de planning en prioritering daarvan.

Resultaat. Per toepassing een ontwerp dat als basis voor implementatie kan dienen, en zicht op wat er per toepassing nog aan besluitvorming of ondersteuning nodig is.

Belegging. De Werkgroep Technische Convergentie, met de referentie-ontwerpen en de kaderkeuzes vanuit de Werkgroep Architectuur.

Afhankelijkheid. Deze opdracht steunt op de referentie-ontwerpen. De volgorde waarin die beschikbaar komen bepaalt dus welke toepassingen als eerste aan de beurt zijn, en dat is een keuze die in samenhang met de behoefte van de toepassingen wordt gemaakt.

Stap 3: implementatie

De implementatie ligt bij de kring Toepassingen en de leveranciers, die dat zelfstandig doen. Vanuit deze kring is er ad-hoc ondersteuning via #development. Blokkades die tijdens de implementatie ontstaan gaan naar de Werkgroep Technische Convergentie, die ze bundelt en bij de kring neerlegt als ze capaciteit of een kaderkeuze vragen.

Deze stap staat hier om de afhankelijkheid zichtbaar te maken, niet omdat de kring er een opdracht in heeft.

Wat er al ligt

Wat Waar Aandachtspunt
Migratiehandleiding voor de node en de use case wiki, v5 naar v6 migration guide Een jaar niet bijgewerkt. Bevat een geordende migratiereeks per use case, en de aanname dat een use case één partij aanwijst die de discovery server host. Die aanname is geen vastgesteld kader.
Deployment- en migratiedocumentatie readthedocs Bijgewerkt in juni 2026. Te beknopt voor beheerders; aanvullingen over poorten en beveiliging zijn toegezegd.
Analyse van de KIK-V-migratie, in twee stappen Slack, #kikv-v6-migratie Bruikbaar als model voor andere toepassingen.
Bevindingenrapportage van Tribe, met de DaaS-leveranciers via KIK-V Geen blockers gevonden voor de node-upgrade.
Inventarisatie per zorgtoepassing, met DID-methode, protocollen en credentials spreadsheet zorgtoepassing-ontwerpers Uit begin 2025, actualisatie nodig.
Ontwerphandleiding voor toepassingen wiki, designing a nuts use case

Openstaande kaderkeuzes

Deze liggen bij de Werkgroep Architectuur en komen als besluit terug in de kring:

Te besluiten

  1. Welke termijn hangen we aan opdracht 1? De node-upgrade is de kritieke voorwaarde voor stap 3 en heeft nu geen einddatum.
  2. Wordt de migratiehandleiding bijgewerkt en als aanbevolen pad vastgesteld, en wie doet dat?

Samenhang met andere trajecten

Wie erbij betrokken zijn

Rol Wie
Opdracht 1, node-upgrade Rein Krul, vanuit het producteigenaarschap
Opdracht 2, ontwerp per toepassing Werkgroep Technische Convergentie
Referentie-ontwerpen en kaderkeuzes Werkgroep Architectuur
Implementatie de toepassingen en hun leveranciers

Hoe haak je aan

Draai je nog op v5 en wil je upgraden, meld je in #development. Gaat het over het omzetten van een toepassing naar did:web, dan loopt dat via de Werkgroep Technische Convergentie.

Projecten

Generieke Functies

Status: Waar: #gf-cot

Wat het is

Relevantie voor Nuts

Wat wij de werkgroep vragen

Planning

Te besluiten

Samenhang met andere trajecten

Bronnen

Wie erbij betrokken zijn

Hoe haak je aan

Deelprojecten

Hosting

De projectgroep wil een test/sandbox omgeving hosten om demo's te kunnen geven en voor leveranciers om tegenaan te testen. In de toekomst kan het zijn dat we naar de gekozen hosting provider, ook andere Nuts services willen migreren (nu alleen de Wiki), want die worden nog gehost door Nedap.

Het selectieproces voor de hosting provider is als volgt:

  1. In kaart brengen requirements (zie GitHub issue)
  2. In kaart brengen hosting providers (zie GitHub issue)
  3. Keuze maken en voorleggen aan Kring Techniek ter goedkeuring
Projecten

Hosting van de GF-testomgeving

Status: besluit voorgesteld. Het is bekrachtigd als er vóór maandag 7 september 2026 geen bezwaar is vanuit de leden van de kring Techniek. Waar: #kring-techniek-pub en #gf-cot

Wat het is

Vanuit project Generieke Functies wordt een test- en sandboxomgeving gebouwd, voor onszelf en voor leveranciers om tegenaan te testen. Het functioneel ontwerp beschrijft wat die omgeving moet doen.

Volgens de huidige praktijk zou die omgeving op de zakelijke hostingomgeving van Rein Krul komen te draaien, zoals de bestaande GF-testomgeving nu ook doet. Nu er meer diensten voor langere tijd gehost gaan worden, is de wens de hosting zo op te zetten dat iedereen binnen het COT haar kan onderhouden. In de huidige omgeving is dat niet mogelijk en niet wenselijk.

Waarom dit langs de kring gaat

Hosting van gedeelde omgevingen valt onder ons mandaat, net als de andere community-tooling en samenwerkingsmiddelen. Het gaat om een structurele voorziening met terugkerende kosten, om een contract dat namens de stichting wordt afgesloten, en om het weghalen van een afhankelijkheid van één persoon.

Het voorstel

Managed Kubernetes bij OVHcloud. Het eerste jaar op maandcontract, zodat er geen langdurige binding ontstaat en overstappen eenvoudig blijft.

Af te nemen diensten:

Na ingebruikname vervalt de hostingomgeving bij Rein.

Kosten. Naar verwachting 1200 tot 1800 euro voor het eerste jaar, ten laste van project GF.

Scope. Vooralsnog alleen diensten van project GF: de nieuwe test- en sandboxomgeving en wat daarvan nu bij Rein draait. Andere Nuts-diensten daar in de toekomst ook hosten wordt niet uitgesloten, maar is geen onderdeel van dit besluit.

Wanneer. Ingang medio 1 oktober 2026, evaluatie na zes maanden op 1 april 2027.

Wie. Het hostingcontract wordt afgesloten door Steven van der Vegt namens het bestuur van Stichting Nuts. Administratieve rechten worden ingericht zoals bij de GitHub-organisatie van Nuts, met dezelfde personen en vergelijkbare rechten. COT-leden krijgen operationele rechten om de omgeving te onderhouden, deployen en debuggen.

De afweging

Overwogen zijn STACKIT, IONOS, OVHcloud, Scaleway, Exoscale, T Cloud Public, Cyso Cloud en Hetzner. Alleen STACKIT, IONOS, OVHcloud en Scaleway scoorden voldoende op alle requirements. Scaleway is afgevallen vanwege slechte ervaringen met de supportdesk, bij Edwin en Formelio en bij Gaspar. Van de overgebleven drie is OVHcloud verreweg het goedkoopst.

Het nadeel van OVHcloud is dat er geen native ondersteuning is voor OpenTelemetry. Uit onderzoek en navraag bij Edwin en Formelio blijkt dat eenvoudig zelf te regelen, zonder veel extra hostingkosten.

De uitgebreide analyse staat in de GitHub-issues, zie Bronnen.

Requirements

Opgesteld door het COT.

Must:

Should:

Te besluiten

Het besluit is voorbereid door het COT en ligt als bezwaarronde bij de kring. Het is bekrachtigd als er vóór maandag 7 september 2026 geen bezwaar is van leden van de kring Techniek.

Samenhang met andere trajecten

Bronnen

Wat Waar
Besluit: hosting test/sandbox-omgeving project GF bij OVHcloud Google Docs
Functioneel ontwerp van de test- en sandboxomgeving Google Docs
Inventarisatie van de requirements nuts-knooppunt issue 528
Onderzoek naar hostingproviders nuts-knooppunt issue 558
OVHcloud ovhcloud.com
Bezwaarronde in de kring, 27 augustus 2026 Slack, #kring-techniek-pub

Wie erbij betrokken zijn

Rol Wie
Voorstel, requirements en selectie Rein Krul, namens het COT
Afsluiten van het hostingcontract Steven van der Vegt, namens het bestuur van Stichting Nuts
Beheer van de omgeving COT-leden, met operationele rechten

Hoe haak je aan

Bezwaar of vragen over de hostingkeuze, vóór 7 september: #kring-techniek-pub. Over de inhoud van de sandboxomgeving: #gf-cot.

Projecten

Vernieuwing van de technische documentatie

Status: in voorbereiding, procesvoorstel ligt bij de kring Waar: #gf-cot en #kring-techniek-pub

Wat het is

In verschillende trajecten van het afgelopen jaar is vastgesteld dat de Nuts-documentatie niet toegankelijk is voor nieuwkomers. Daardoor is het moeilijker dan nodig om Nuts te begrijpen of ermee aan de slag te gaan. Het Centraal Ontwikkel Team werkt hieraan vanuit project Generieke Functies en heeft een procesvoorstel gemaakt om de vernieuwing aan te pakken.

De klachten die daaraan ten grondslag liggen:

Relevantie voor Nuts

De documentatie is onderdeel van hoe wij onze standaarden en implementaties beheren en uitdragen, en de omgevingen waarin zij staat vallen onder community-tooling en samenwerkingsmiddelen. De reikwijdte van dit traject omvat naast de knooppunt-documentatie ook de documentatie van de nuts-node en de specificaties, en raakt daarmee ook Beheer en doorontwikkeling nuts-node.

Beoogde uitkomst

Een eenduidige, goed doorzoekbare set documentatie met een duidelijke inhoudsopgave. Tekortkomingen worden opgehaald door met de community te praten; tooling wordt vernieuwd waar nodig, met consent van de huidige eigenaren van die bronnen. Het resultaat wordt getoetst door feedback te vragen aan de verschillende gebruikersgroepen.

Het proces

Stap Wat
1 Inventariseren: welke bronnen zijn er, met welk doel, voor welk publiek, wie schrijft ze en wat is de kwaliteit. En welke persona's willen we bedienen.
2 Wensen vaststellen: interviews met vertegenwoordigers van stakeholders, aanvullende wensen ophalen en bestaande adviezen verwerken, zoals het rapport van ActiZ en InfoZorg. Resultaat is een doelsituatie met requirements voor inhoud en tooling.
3 Selectie van documentatie-tooling, op basis van onderzoek naar de opties.
4 Voorstel tot verbetering: welke bronnen samengevoegd, verwijderd of gearchiveerd, geherstructureerd of uitgebreid moeten worden.
5 Prototype ontwikkelen, met voorbeelddocumentatie in de gekozen tooling.
6 Voorstel aan de kring Toepassingen en de kring Techniek: gaan we de documentatie herzien volgens dit prototype?
7 Realisatie: nieuwe systemen opzetten, content migreren, publiceren, nieuwe documentatie schrijven en de bestaande herstructureren.

Stap 6 is het besluitmoment. Voordat er iets aan de huidige documentatie verandert, ligt er een inhoudelijk plan bij de kringen. De kringen worden uitgenodigd een afgevaardigde aan het proces te laten deelnemen.

Wat er al ligt

Het document bevat naast het procesvoorstel ook een vooronderzoek en een eerste vernieuwingsvoorstel:

Wat er nu speelt

Het procesvoorstel is op 13 augustus 2026 gedeeld in #kring-techniek-pub en geagendeerd voor de kringvergaderingen van 20 en 27 augustus. Twee commentaarpunten zijn verwerkt. Eén punt is blijven staan: de scope van het traject. De uitkomst van de behandeling is niet vastgelegd in het logboek.

Daarnaast loopt een discussie over twee parallelle sporen en over het ontwikkelen van een prototype.

Te besluiten

  1. Onderschrijft de kring het procesvoorstel en de reikwijdte daarvan, inclusief de nuts-node-documentatie en de specificaties?
  2. Vaardigt de kring iemand af naar dit proces?

Samenhang met andere trajecten

Bronnen

Wat Waar
Procesvoorstel Vernieuwing Nuts Documentatie, met vooronderzoek en vernieuwingsvoorstel Google Docs
Aankondiging en verzoek om commentaar, 13 augustus 2026 Slack, #kring-techniek-pub

Wie erbij betrokken zijn

Rol Wie
Procesvoorstel en uitvoering Rein Krul en Dirk Geurs, namens het COT
Afvaardiging vanuit de kring Techniek nog te bepalen
Afvaardiging vanuit de kring Toepassingen nog te bepalen

Hoe haak je aan

Heb je last van de huidige documentatie of wil je meedenken over de nieuwe opzet, laat het weten in #gf-cot of in #kring-techniek-aanspreekpunt.

Projecten

POC TTA Notifications v0.6

Status: in uitvoering
Opdrachtgever: Steven van der Vegt, coördinator Kring Techniek
Uitvoering: Gasper, vanuit het COT
Type: operationele opdracht van de coördinator, ter mededeling in de kringvergadering

Wat

Bouw een proof of concept van de TTA Notifications v0.6 in het knooppunt, op een losse branch. De nadruk ligt op het beantwoorden van de onderzoeksvragen, niet op de code. De code is wegwerpcode en hoeft niet aan de gebruikelijke kwaliteitseisen te voldoen. Of en in welke vorm het naar main gaat, besluiten we daarna op basis van de conclusies.

De POC implementeert beide rollen uit de TTA:

Optionele features en permutaties. De TTA laat een aantal keuzes open: in-band of out-of-band, heartbeat wel of niet, $events wel of niet, empty of id-only. Optionele features zijn meestal het resultaat van een onderhandeling waarin de ene partij iets belangrijk vond en de andere niet. De vraag is wat er gebeurt als die twee partijen samen gaan uitwisselen. Onderdeel van de opdracht is daarom de combinaties van deze keuzes te beproeven tussen een server en een client die verschillende keuzes maken. Als dat in code te duur wordt, mag het in de analyse worden afgehandeld, met per combinatie wat er volgens de spec zou moeten gebeuren en waar de spec dat open laat.

De TTA werkt authenticatie en autorisatie niet uit. Voor de POC mogen die worden gemockt, maar het is wel een onderzoeksvraag.

Waarom

  1. Feedback op de specificatie naar Twiin. Wij schrijven mee aan de harmonisatie van de TA Notified Pull en de TTA Notifications is daar het eerste resultaat van, zie Harmonisatie TA Notified Pull. Een implementatie is de snelste manier om te zien of de specificatie volledig en consistent is. De bevindingen brengen we in via de subwerkgroep en de consultatie van Twiin najaarsrelease 1.6.
  2. Input voor de toepassingen. De toepassingen (eOverdracht voorop) moeten een impactanalyse doen op de nieuwe TTA. Een referentie in het knooppunt laat zien wat er op hen afkomt en wat het knooppunt daarvan voor hen kan afvangen.

Onderzoeksvragen

  1. Is de specificatie volledig en correct? Waar loop je vast, waar moet je zelf een keuze maken die de spec had moeten maken, waar spreekt de spec zichzelf tegen?
  2. Hoeveel werk is het om te implementeren?
  3. Hoeveel werk neemt een referentie-implementatie in het knooppunt de implementator uit handen? Is de abstractie voldoende, of bouw je alsnog alles in je eigen applicatie? Wat beheert het knooppunt (subscriptionstate, event-numbers, retry, heartbeats) en wat blijft bij de toepassing?
  4. Op welke onderdelen helpt de knooppunt-implementatie je concreet, en op welke niet?
  5. Hoe past authenticatie en autorisatie in ons model? Waar landen de verplichte autorisatie- en consentchecks (voor activatie en voor iedere notificatie) in het knooppunt, en hoe verhoudt de mTLS-eis uit de TTA zich tot ons model? Is de autorisatiehint uit de huidige Twiin TA NP een zinvol onderdeel van de notificatie?
  6. Optionele features. Wat gebeurt er als server en client verschillende keuzes maken op de optionele onderdelen? Waar gaat het mis en zegt de spec daar iets over?
  7. FHIR-versie. De TTA schrijft R4 of R4B voor voor het subscriptionframework. De eOverdracht zit op STU3. Werkt het framework naast STU3-resources, en wat betekent dat voor een toepassing?
  8. Id-only eisen. De TTA stelt eisen aan resource-identifiers (stabiel, opaak, onvoorspelbaar). Voldoen de identifiers die onze toepassingen en gangbare FHIR-servers nu uitgeven daaraan? Zo niet, wat is de consequentie?
  9. Adressering. Hoe lost het knooppunt het notificatie-endpoint en het Subscription-endpoint op via GF Adressering (mCSD, Endpoint met payloadType Subscription)?
  10. Verschil met nu. Wat is het verschil met de huidige eOverdracht-notificatie en met de Nuts-variant van de TA NP, en wat is grofweg het migratiepad?

Wanneer

Wie

Waar

Resultaat

  1. Werkende POC op een branch, beide rollen, demonstreerbaar.
  2. Een demo.
  3. Een deelbaar bevindingendocument met antwoorden op de onderzoeksvragen, met twee delen: fouten en gaten in de specificatie (naar Twiin) en implementatie-impact (naar de toepassingen).
  4. Een korte conclusie voor de werkgroep Technische Convergentie als input voor de impactanalyse van de toepassingen.

Samenhang met andere trajecten

Bronnen

Wat Waar
TTA Notifications v0.6 ontwikkelsupplement.twiin.nl
Concept notificatiespecificatie in de generieke-functies-IG build.fhir.org
Integratiefase: plan en budget, mei 2026 Google Doc
Oproep aan de eOverdracht-deelnemers over de impactanalyse, augustus 2026 Slack, #kring-toepassingen
Bespreking en toewijzing in het COT-planningsoverleg, 7 september 2026 COT logboek operationeel overleg

Externe gremia en verzoeken

Externe gremia en verzoeken

Twiin najaarsrelease 1.6

Status: gevraagd, nog niet belegd Waar: #kring-techniek-pub

Wat het is

Het Twiin Afsprakenstelsel kent twee releases per jaar, met per release een consultatieronde. De voorbereiding van de najaarsrelease (versie 1.6) is in juli 2026 gestart. De planning is op 17 juli bij de kring neergelegd, met de vraag of wij hierop willen reageren en zo ja wie dat doet en wanneer.

Relevantie voor Nuts

In opeenvolgende Twiin-releases worden steeds meer onderdelen uit de programma's Landelijk dekkend netwerk (LDN), Implementatie generieke functies (IGF) en Landelijk afsprakenstelsel (LAS) opgenomen. Wat in een release landt, wordt normatief voor partijen die zich aan het Twiin-stelsel conformeren.

Twee dingen maken deze release voor ons specifiek van belang.

De geharmoniseerde TA Notified Pull is beoogd voor versie 1.6. Twiin heeft in mei bevestigd dat de TA NP die nu in het stelsel staat uit 2024 komt, en dat de geharmoniseerde versie waaraan de subwerkgroep werkt in de najaarsrelease wordt opgenomen, waarna de huidige versie wordt verwijderd. Wij nemen aan die harmonisatie deel, zie Harmonisatie TA Notified Pull. Het notificatiedeel is op 27 augustus als TTA Notifications v0.6 gepubliceerd. Het COT beproeft die specificatie in een POC, zie POC TTA Notifications v0.6; de bevindingen daaruit zijn input voor onze consultatiereactie.

Daarnaast raakten de wijzigingen in de voorjaarsrelease 1.5.0 ons domein rechtstreeks: de eisen voor de generieke functies identificatie en authenticatie, autorisatie, toestemming, logging en adressering zijn herschreven, het communicatiepatroon Notified Pull is herzien en de eisen rond Veilig Netwerk zijn toegevoegd. Dat zijn onderwerpen waarvoor de kring eigen kaders en implementaties beheert.

Voorgestelde opdracht

De kring stelt een opdracht in om namens Nuts te reageren op de consultatie van de Twiin najaarsrelease 1.6.

Doel. Borgen dat de eisen die Twiin normatief maakt op onderdelen die de kring beheert of specificeert, aansluiten bij onze technische kaders, en dat de geharmoniseerde TA Notified Pull correct in het stelsel landt.

Scope. De opdracht richt zich op:

Buiten scope vallen: eisen over bedrijfsvoering, organisatie en beveiligingsmaatregelen bij deelnemers, zorgtoepassingsspecifieke eisen zoals de validatie- en ketentest-eisen voor BgZ, de Twiin-diensten en -processen zoals validatie, incidentmelding en ketenregie, en redactionele keuzes over views en presentatie. Deze afbakening voorkomt dat de opdracht uitloopt op een review van het hele afsprakenstelsel.

Resultaat. Een ingediende consultatiereactie namens de kring, en een korte terugkoppeling aan de kring over wat is ingebracht en wat Twiin daarmee heeft gedaan.

Belegging. De werkgroep Architectuur in oprichting is de waarschijnlijke plek voor deze opdracht. Die werkgroep krijgt als taak architectuurvraagstukken op te pakken en besluitrijp te maken voor de kring, en deze consultatie past daarbinnen. Wordt de werkgroep niet tijdig ingesteld, dan belegt de kring de opdracht rechtstreeks.

Werkwijze. De opdracht wordt door ten minste twee mensen uitgevoerd, zodat de doorlooptijd niet van één agenda afhangt. De consultatieperiode loopt van 5 oktober tot en met 30 oktober, met daarbinnen twee online consultatiesessies. De expertsessie in week 46 en de overlegtafels in week 48 gaan op persoonlijke uitnodiging; deelname daaraan wordt tijdig met Twiin afgestemd.

Input voor de opdracht

Bij de voorjaarsrelease 1.5.0 is de indieningstermijn van 28 april niet gehaald. De observaties die toen zijn opgesteld zijn daardoor niet als consultatiereactie ingediend en gelden als input voor deze ronde:

Voor de TA Notified Pull komt de input uit de POC TTA Notifications v0.6: het bevindingendocument daarvan bevat een deel met fouten en gaten in de specificatie dat bedoeld is om via de subwerkgroep en de consultatie bij Twiin in te brengen.

Over de eisen rond Veilig Netwerk is eerder onduidelijkheid geweest over de relevantie en de impact. De analyse daarvan staat op de pagina Verwijzen naar het Landelijk afsprakenstelsel: de eisen zijn organisatorisch van aard, er valt niets aan te implementeren in de nuts-node of in onze profielen, en inhoudelijke vragen erover horen bij LDN als bron en niet bij Twiin als publicerende partij. Brengt de najaarsrelease hier nieuwe wijzigingen in, dan volgt de opdracht diezelfde lijn.

Planning van de najaarsrelease

Wanneer Wat
Juli tot begin oktober Twiin werkt de inhoud van de release uit met werkgroepen en experts
Week 37 Eerste inhoudelijke informatie over de release en de consultatieonderwerpen
September POC TTA Notifications v0.6 door het COT, voorstel oplevering 21 september
5 oktober Start consultatie
Oktober Twee online consultatiesessies
30 oktober Einde consultatie, vier weken vanwege de herfstvakantie
Week 46 Expertsessie over de wijzigingen en de ontvangen feedback, op persoonlijke uitnodiging
Week 48 Overlegtafels Twiin Deelnemers en Dienstverleners en de overlegtafel GTK's, die hun advies vormen
Vanaf 14 december Publicatie van de definitieve najaarsrelease

Deze planning is door Twiin gedeeld als beoogd en kan nog wijzigen.

Te besluiten

De eerste inhoudelijke informatie komt in week 37, halverwege september. Besluitvorming daarvoor:

  1. Geeft de kring consent op de opdracht zoals hierboven beschreven?
  2. Klopt de scope, of ontbreekt er een onderwerp dat wel onder onze kaders valt?
  3. Belegt de kring de opdracht bij de werkgroep Architectuur, en wie voeren hem uit met welke tijdsbesteding?
  4. Wie vertegenwoordigt de kring bij de expertsessie en, indien van toepassing, bij de overlegtafels?

Samenhang met andere trajecten

Bronnen

Wat Waar
Aankondiging planning najaarsrelease, 17 juli 2026 Slack, #kring-techniek-pub
Uitnodiging gerichte consultatie 1.5.0 met de lijst consultatieonderwerpen, 21 april 2026 Slack, #haagsezaken en mail van info@twiin.nl
Vraag aan de kring wie meeleest op 1.5.0, 21 april 2026 Slack, #kring-techniek-pub
Observaties bij 1.5.0, 7 mei 2026 Slack, #haagsezaken
Terugkoppeling aan Twiin en vraag over de timing van de TA NP-eisen, 7 mei 2026 mail van Steven van der Vegt aan Team Twiin
Antwoord van Twiin over TA NP en release 1.6, 8 mei 2026 mail van Anneke Huisman
Terugkoppeling consultatie 1.5.0 met gebundelde reacties van alle partijen, 6 mei 2026 mail van info@twiin.nl
TTA Notifications v0.6, 27 augustus 2026 ontwikkelsupplement.twiin.nl
Consultatieplatform Twiin consultatie.twiin.nl
Twiin Afsprakenstelsel, normatief afsprakenstelsel.twiin.nl

Wie erbij betrokken zijn

Rol Wie
Signalering en contact met Twiin Sergej van Middendorp
Deelname werkgroep TA en harmonisatie TA NP Steven van der Vegt
Uitvoering van de opdracht nog te bepalen, voorzien bij de werkgroep Architectuur in oprichting

Contact bij Twiin: Anneke Huisman voor de inhoud van de TA's, info@twiin.nl voor de consultatie.

Hoe haak je aan

Wil je meeschrijven aan de reactie of meelezen op de consultatieonderwerpen, laat het weten in #kring-techniek-aanspreekpunt.

Externe gremia en verzoeken

PKIOverheid G4-transitie

Status: in voorbereiding Waar: #kring-techniek-pub

Wat het is

Vanaf 12 november 2026 geven het UZI-register en de andere PKIoverheid-uitgevers een nieuwe generatie certificaten uit: G4. Daarbij verandert de CA-hiërarchie en wijzigen velden en attributen in de UZI-certificaten, onder meer het veld met het URA-nummer.

De vraag is langs twee wegen bij de kring gekomen. Diana Demmer (ActiZ) vroeg op 14 juni via Sergej van Middendorp of, en zo ja in hoeverre, de PKIO-migratie die VZVZ aankondigt ook impact heeft op applicaties die met Nuts werken, en of wij daar iets mee moeten. Jorrit Spee stelde de vraag op 25 juni rechtstreeks aan de kring: hoe moeten wij ons hierop voorbereiden?

Relevantie voor Nuts

PKIoverheid-certificaten zijn in het Nuts-netwerk in gebruik voor TLS en mTLS, en UZI-certificaten worden gebruikt om Verifiable Credentials uit te geven en te valideren. Dat laatste is beschreven in RFC023 X509Credential: de houder van een UZI-certificaat geeft een X509Credential uit vanuit een did:x509, waarbij het vertrouwen wordt verankerd in de ca-fingerprint, de hash van de root- of intermediate-CA. Attributen uit het certificaat, waaronder het URA-nummer in san:otherName, komen daarmee in de credential terecht.

Dat heeft drie soorten gevolgen.

Trust anchors. Een nieuwe CA-hiërarchie betekent nieuwe hashes. Waar wij of een toepassing een ca-fingerprint vastleggen, moet die worden aangevuld of vervangen. Truststores en intrekkingscontrole moeten met de nieuwe hiërarchie overweg kunnen.

Toepassingen en hun presentation definitions. Per use case staan de geaccepteerde trust anchors in de presentation definition. Bij ACP/PZP is het G4 UZI-testcertificaat op 30 juni toegevoegd, zie PR 3 op application-on-nuts-acp-pzp. Dezelfde stap is nodig voor de andere toepassingen, waaronder Huisartsinzage, en de bijbehorende documentatie moet met de nieuwe hashes worden bijgewerkt. Zolang dat niet gebeurd is, worden credentials op basis van een G4-certificaat niet geaccepteerd.

Attributen en validatie. Wijzigt de plaats of de vorm van het URA-nummer of van andere attributen, dan raakt dat de opbouw van de did:x509, de credentialSubject en de validatieregels die daarop zitten.

Er is al enige praktijkervaring: in de PoC's rond de generieke functies is in april 2026 met G4 TRIAL-certificaten gewerkt en zijn de TRIAL- en productie-G4-roots in truststores opgenomen.

De datum ligt vast en is niet te beïnvloeden, dus dit is een van de weinige punten op deze lijst met een harde deadline.

Voorgestelde opdracht

De kring stelt een opdracht in om de impact van de PKIOverheid G4-transitie in beeld te brengen en de benodigde aanpassingen te laten plaatsvinden.

Doel. Zorgen dat deelnemers en toepassingen vóór 12 november 2026 klaar zijn om met G4-certificaten te werken in het Nuts-netwerk, en dat helder is wat wij daarvoor leveren en wat deelnemers zelf doen.

Scope. De opdracht richt zich op:

Buiten scope vallen: het aanvragen en beheren van certificaten door individuele deelnemers, de transitie binnen hun eigen infrastructuur, en het beleid van Logius en het UZI-register.

Resultaat. Een analyse met de verschillen tussen de oude en nieuwe generatie en de gevolgen daarvan, een lijst met aanpassingen per component en per toepassing, en een korte tekst richting deelnemers. Terugkoppeling in de kring.

Belegging. Het onderzoek is opgepakt vanuit het producteigenaarschap van de nuts-node en loopt via issue 4355. Voorstel is om die lijn te bevestigen en de opdracht daar formeel te beleggen. De aanpassingen per toepassing liggen bij de toepassingen zelf; onze rol daar is signaleren wat er moet gebeuren en ondersteunen.

Werkwijze. Analyse eerst, dan pas ontwikkelwerk. Wat uit de analyse volgt aan aanpassingen komt op de backlog van de nuts-node en wordt langs de gebruikelijke weg geprioriteerd. Wat bij toepassingen ligt, gaat via de kring Toepassingen en het convergentieoverleg. Het handelingsperspectief voor deelnemers gaat via de gebruikelijke kanalen naar buiten, in afstemming met ActiZ waar dat helpt.

Input voor de opdracht

VZVZ heeft op de Netwerkdag van 25 juni een sessie gehouden over de PKI G4-transitie, met aandacht voor de impact op zorgapplicaties, netwerkcommunicatie en authenticatie, en voor de ondersteuning die VZVZ zelf biedt. Het is de moeite waard om te weten wat daar is verteld voordat wij deelnemers apart gaan informeren.

Planning

Alleen de laatste stap heeft een vaste datum. De stappen daarvoor werken daar naartoe en krijgen hun data bij het beleggen van de opdracht.

Stap Wat Wanneer
1 Opdracht beleggen en scope bevestigen in de kring eerstvolgende kringvergadering
2 Analyse opleveren: verschillen tussen de generaties, impact per component en per toepassing nader te bepalen
3 Aanpassingen doorvoeren in de nuts-node en het knooppunt, en releasen nader te bepalen
4 Presentation definitions en documentatie per toepassing bijwerken nader te bepalen
5 Deelnemers informeren over wat zij zelf moeten doen ruim voor stap 6
6 Start uitgifte van G4-certificaten 12 november 2026

Te besluiten

  1. Geeft de kring consent op de opdracht zoals hierboven beschreven?
  2. Klopt de scope, en met name de afbakening dat wij niet over de transitie bij deelnemers zelf gaan?
  3. Bevestigt de kring de belegging bij het producteigenaarschap van de nuts-node, en met welke tijdsbesteding?
  4. Welke einddata hangen we aan de stappen 2 tot en met 5?
  5. Langs welke weg brengen we de aanpassingen per toepassing onder de aandacht bij de kring Toepassingen?

Samenhang met andere trajecten

Bronnen

Wat Waar
Vraag van Diana Demmer via Sergej van Middendorp, 14 juni 2026 Slack, #kring-techniek-pub
Vraag van Jorrit Spee aan de kring, met de externe links, 25 juni 2026 Slack, #kring-techniek-pub
Onderzoek naar de impact op de nuts-node nuts-node issue 4355
G4 UZI-testcertificaat vertrouwd voor ACP/PZP, 30 juni 2026 PR 3
Agendapunt VZVZ Netwerkdag over de PKI G4-transitie, 25 juni 2026 Slack, #gf-cot
Werken met G4 TRIAL-certificaten in de GF-PoC's, april 2026 Slack, #gf-poc-3-poc-12
ActiZ-artikel over de G4-certificaten, 5 augustus 2026 Slack, #haagsezaken, met pdf

Wie erbij betrokken zijn

Rol Wie
Vraagstellers Jorrit Spee en Diana Demmer (ActiZ)
Onderzoek en producteigenaarschap nuts-node Rein Krul
Ervaring met G4 in toepassingen Edwin Rozendom (Topicus), vanuit ACP/PZP
Communicatie richting deelnemers nog te bepalen

Hoe haak je aan

Loop je zelf tegen vragen aan over de G4-transitie in combinatie met Nuts, of heb je al ervaring met G4-certificaten in je eigen omgeving, meld het in #kring-techniek-aanspreekpunt.

Externe gremia en verzoeken

Harmonisatie TA Notified Pull

Status: loopt Waar: #kring-techniek-pub

Wat het is

Het Twiin Afsprakenstelsel bevat een Technische Afspraak Notified Pull (TA NP) uit 2024. Twiin heeft vanuit het programma Landelijk dekkend netwerk (LDN) de opdracht om die afspraak te harmoniseren tot een generiek bouwblok, en heeft daarvoor een subwerkgroep ingericht onder de Working Group TA (WGTA). Nuts neemt daar sinds het voorjaar van 2026 aan deel; het meeschrijven aan de Twiin TA NP staat als doorlopend werk in ons jaarplan.

De harmonisatie is opgedeeld in een notificatiedeel en een workflowdeel. Beide liggen bij deze werkgroep. Het notificatiedeel wordt als eerste uitgewerkt, als TA Notificaties.

Relevantie voor Nuts

De geharmoniseerde TA NP wordt een generiek bouwblok in het landelijk dekkend netwerk. Wat daar wordt vastgelegd, bepaalt hoe gegevensuitwisseling met notificatie in Nederland technisch werkt.

Het gaat om meer dan notificeren. Zowel de bestaande TA NP van Twiin als de Nuts-variant hebben een flink aantal generieke functies in scope: naast notificatie ook adressering, lokalisatie, toestemming, autorisatie en identificatie en authenticatie. De harmonisatie moet die dus allemaal behandelen. Authenticatie en autorisatie zijn daarbij een zwaar onderdeel, omdat de vertrouwensmodellen van Twiin en Nuts fundamenteel van elkaar verschillen: in ons ontwerp worden rollen en claims cryptografisch aangetoond op de lijn met Verifiable Credentials, terwijl het Twiin-model daar anders in staat. Dat vraagstuk is inmiddels als apart traject bij VWS belegd, zie Reactie op de VWS-memo Harmonisatie van Authenticatie en Autorisatie.

Er blijft profilering nodig na de TA's. De TA NP en de TA Notificaties zijn bouwblokken. Zoals het er nu uitziet moeten toepassingen daarbovenop nog eigen keuzes maken over details, dus profileren op de TA's. Voor de eOverdracht betekent dat dat er na de TA's nog een toepassingsprofiel moet komen. Wie dat opstelt is nog niet duidelijk: het programma eOverdracht of Twiin. Dat is een vraag die we tijdig geagendeerd willen hebben, want daar hangt aan vast wie het werk doet en wanneer het klaar kan zijn.

Het raakt de vernieuwing van de eOverdracht-standaarden. De huidige eOverdracht-implementatie in de Nuts community is gebaseerd op oudere afspraken; de X509Credential en de nieuwere autorisatieaanpak maken daar geen deel van uit. De kring Toepassingen wil die standaarden zelf vernieuwen, als onderdeel van de migratie naar Nuts v6. Wat hier in de harmonisatie wordt vastgelegd, is input voor die vernieuwing.

Het landt in de Twiin najaarsrelease. Twiin heeft bevestigd dat de geharmoniseerde versie in release 1.6 wordt opgenomen en dat de versie uit 2024 daarna wordt verwijderd. Zie Twiin najaarsrelease 1.6.

Opdracht

De kring bevestigt de deelname aan dit traject en legt de opdracht als volgt vast.

Doel. De geharmoniseerde TA Notified Pull technisch werkbaar en in lijn met de Nuts-uitgangspunten laten landen in het Twiin Afsprakenstelsel, en tijdig in beeld hebben wat het resultaat betekent voor onze toepassingen en implementaties.

Scope. De opdracht omvat:

Buiten scope valt de inrichting van de governance van het Twiin-stelsel en van het LDN-programma. Wij brengen inhoudelijke argumenten in; het proces en de samenwerking daarover liggen bij de kring Gezamenlijk Belang.

Resultaat. Ingebrachte inhoudelijke bijdragen en reacties, een geharmoniseerde TA die in release 1.6 kan landen, en een beeld van de gevolgen voor onze eigen techniek en toepassingen.

Belegging. De deelname is belegd bij Steven van der Vegt, met Dirk Geurs als tweede deelnemer. De impactanalyse eOverdracht wordt vanuit de kring Toepassingen georganiseerd, met achtergrond en kennis vanuit deze kring.

Werkwijze. De subwerkgroep vergadert wekelijks op dinsdagochtend. Inhoudelijke stukken komen per mail en via de Twiin-tooling. Vraagstukken die een kaderkeuze raken komen naar de kring; de werkgroepdeelname zelf vraagt geen besluitvorming per onderwerp.

Openstaande inhoudelijke punten

Deze punten zijn ingebracht of geconstateerd en zijn nog niet opgelost:

Planning

Wanneer Wat
Wekelijks, dinsdagochtend Subwerkgroep Harmonisatie TA NP
Periodiek Working Group TA (WGTA), overkoepelend
24 augustus Reacties op de oproep aan de eOverdracht-deelnemers over de impactanalyse
27 augustus TTA Notifications v0.6 gepubliceerd in het Twiin ontwikkelsupplement
September POC TTA Notifications v0.6 door het COT, voorstel oplevering 21 september
Week 37 Eerste inhoudelijke informatie over Twiin release 1.6
5 oktober tot 30 oktober Consultatie Twiin release 1.6
Vanaf 14 december Publicatie release 1.6, met de geharmoniseerde TA NP

Te besluiten

  1. Neemt Nuts zitting in de subwerkgroep TA Pull? Dit is vanuit VZVZ voorgesteld, zodat de ontwikkeling binnen LSP x Nuts in lijn blijft met de TA Pull. Voorstel is om niet deel te nemen aan TA Indexed Pull, omdat die over beeld gaat en voor ons beperkt relevant is.
  2. Hoe verhoudt de inbreng in dit traject zich tot de openstaande kaderkeuzes over authenticatie en autorisatie? Voorstel is om die keuzes expliciet in de kring te maken in plaats van ze impliciet in werkgroepbijdragen te laten ontstaan.
  3. Langs welke weg wordt de kring geïnformeerd over de voortgang, gegeven het wekelijkse ritme van de werkgroep?

Samenhang met andere trajecten

Bronnen

Wat Waar
Start van de subwerkgroep Harmonisatie TA NP, april 2026 mailwisseling met Anneke Huisman (Twiin), met de aanpak en de bespreekpunten
Vragen over de scope van subscriptions om de oplossingsruimte te beperken, 21 mei 2026 mail van Steven van der Vegt aan Twiin en VWS
Uitwerking van de subscription topics voor de niveaus L1 tot en met L4, 5 juni 2026 mail van Steven van der Vegt aan de werkgroep
Notities van de werkgroepbijeenkomsten, vanaf 30 juni 2026 Slack DM Dirk Geurs
Voorstel van VZVZ om namens LSP x Nuts deel te nemen aan de TA Pull, 15 juni 2026 Slack, #kring-techniek-pub
Documenten voor de TA-bijeenkomst, 27 juli 2026 mail van Arnaud Poelman (Twiin)
Notulen en acties WGTA mails van Siu Luc en Jelmer Kranenburg (Twiin)
Oproep aan de eOverdracht-deelnemers over de impactanalyse, 4 augustus 2026 Slack, #kring-toepassingen
TTA Notifications v0.6, 27 augustus 2026 ontwikkelsupplement.twiin.nl
Twiin over de TA Pull als generiek bouwblok ontwikkelsupplement.twiin.nl
Concept notificatiespecificatie in de generieke-functies-IG build.fhir.org
Bevestiging dat de geharmoniseerde TA NP in release 1.6 landt, 8 mei 2026 mail van Anneke Huisman

Wie erbij betrokken zijn

Rol Wie
Deelname subwerkgroep Harmonisatie TA NP Steven van der Vegt en Dirk Geurs
Deelname WGTA Steven van der Vegt
Deelname TA Pull namens LSP x Nuts nog te bepalen

Bij Twiin: Anneke Huisman en Arnaud Poelman voor de inhoud van de TA's, Siu Luc en Jelmer Kranenburg voor de WGTA. Andere deelnemers aan de subwerkgroep komen onder meer van VZVZ, Chipsoft, Nedap, Nexus, Cumuluz en VWS.

Hoe haak je aan

Wil je meelezen op de concepten of meedenken over de gevolgen voor een toepassing, laat het weten in #kring-techniek-aanspreekpunt. Voor de eOverdracht loopt de afstemming via #kring-toepassingen.

Externe gremia en verzoeken

Reactie op de VWS-memo Harmonisatie van Authenticatie en Autorisatie

Status: reactie verzonden op 19 augustus 2026. Nu verder bespreken met VWS. Waar: #kring-techniek-pub

Wat het is

Bij VWS lag de vraag hoe om te gaan met authenticatie en autorisatie bij notified pull. Een werkgroep van VWS heeft daarover een memo opgesteld, "Harmonisatie van Authenticatie en Autorisatie", met een advies. Marc Hoekstra (implementatiemanager generieke functies, directie Informatiebeleid/CIO) heeft die uitkomst op 14 juli met Nuts gedeeld en om een reactie gevraagd. Op 15 juli is het advies in een half uur toegelicht door de werkgroep die het heeft opgesteld.

De reactietermijn van VWS liep tot 10 augustus. Namens Nuts is uitstel gevraagd omdat de termijn in de vakantieperiode viel; de reactie is op 19 augustus verzonden.

Relevantie voor Nuts

Het advies bepaalt hoe vertrouwen wordt geregeld bij notified pull, en het uitgesproken doel is om die lijn daarna uit te breiden naar andere use-cases. De strekking reikt dus verder dan één communicatiepatroon.

Dat raakt de kern van waar Nuts over gaat: in ons ontwerp worden organisatiekenmerken, attributen en delegaties cryptografisch aangetoond met Verifiable Credentials, controleerbaar op herkomst, geldigheid en intrekking. Het advies kiest een andere richting. Wat hier wordt vastgelegd, werkt door in de harmonisatie van de TA Notified Pull, in de generieke functies en in het technisch profiel van de toepassingen die daarop gaan bouwen.

Daarnaast raakt het advies onze eigen techniek rechtstreeks. Wij gebruiken UZI-servercertificaten niet alleen voor het beveiligen van verbindingen maar ook voor het uitgeven van credentials, zie RFC023 X509Credential. Een advies dat sterk op dat certificaat leunt heeft dus gevolgen voor de manier waarop wij vertrouwen opbouwen, en niet alleen voor de vraag wie een certificaat moet aanschaffen.

Opdracht

Doel. Een inhoudelijke reactie op de memo leveren die het Nuts-standpunt over authenticatie en autorisatie helder neerzet, met een technische en juridische onderbouwing en een voorstel voor de doelarchitectuur en het pad daarnaartoe.

Scope. De reactie bevat een technische analyse van het voorgestelde model, een juridische analyse, een voorstel voor een doelarchitectuur (SOLL) met een plateau-indeling zodat onderscheid ontstaat tussen wat nu kan en waar we naartoe werken, en gerichte vragen aan VWS over de status van het advies en het vervolgproces.

Resultaat. Een ingediende reactie namens Nuts, en helderheid over hoe VWS het vervolg organiseert. Omdat de termijn kort is en in de vakantieperiode viel, wordt de mogelijkheid open gehouden om na nadere analyse aanvullingen te doen.

Belegging. De reactie is opgesteld door Steven van der Vegt, op basis van een eerdere interne analyse. Sergej van Middendorp heeft de eerste delen gereviewd en onderhoudt namens de kring Gezamenlijk Belang het contact met VWS over het proces. Dit type opdracht is bij uitstek werk voor de werkgroep Architectuur in oprichting, die dit zelfstandig zou moeten kunnen oppakken en besluitrijp maken voor de kring.

Werkwijze. Rein Krul en Dirk Geurs reviewen de reactie voor verzending. Het technische deel is eerder al gereviewd in de interne analyse.

Wat er nu speelt

Planning

Wanneer Wat
14 juli Memo gedeeld met Nuts, met verzoek om reactie
15 juli Toelichting door de VWS-werkgroep
10 augustus Reactietermijn van VWS, uitstel gevraagd
19 augustus Verzending van de reactie namens Nuts
22 augustus VWS deelt de samenvatting van elf reacties
28 augustus Sessie met VWS over de reacties en oplossingsrichtingen
21 september Terugkoppeling als mededeling in de kringvergadering
nader te bepalen Vervolgproces bij VWS

Terugkoppeling aan de kring

Deze reactie komt als mededeling terug in de eerstvolgende kringvergadering: wat er is ingediend, wat VWS ermee doet en hoe het vervolgproces eruitziet. Als daar punten uit komen die een kaderkeuze raken, agenderen we die als apart punt.

Samenhang met andere trajecten

Bronnen

Wat Waar
Verzoek om reactie op het A&A-advies, 14 juli 2026 mail van Marc Hoekstra (VWS)
Melding aan VWS dat de reactie een week later komt, 10 augustus 2026 mail van Sergej van Middendorp
Onze reactie op de memo, met de vraag om review, 7 augustus 2026 Slack, #kring-techniek-pub
Vraag om review in het COT, 7 augustus 2026 Slack, #gf-cot
Afstemming met Nedap over hun eigen reactie, 6 en 7 augustus 2026 Slack DM Roald Dijkstra
Samenvatting van alle elf reacties en uitnodiging voor de sessie, 22 augustus 2026 mail van Sandra Craandijk (VWS), gedeeld in Slack
Reactie van VZVZ op de harmonisatiedocumenten, 26 augustus 2026 mail van Jeroen Bos (VZVZ)
RFC023 X509Credential, over het gebruik van UZI-certificaten voor credentials gitbook

Wie erbij betrokken zijn

Rol Wie
Opstellen van de reactie Steven van der Vegt
Review Sergej van Middendorp, Rein Krul, Dirk Geurs
Sessie met VWS op 28 augustus Steven van der Vegt, Roland Groen
Contact met VWS over het proces Sergej van Middendorp, namens de kring Gezamenlijk Belang

Bij VWS: Marc Hoekstra als implementatiemanager generieke functies, Sandra Craandijk voor het reactieproces. Het advies is opgesteld door een werkgroep van VWS.

Hoe haak je aan

Heb je inhoudelijke punten over authenticatie en autorisatie bij notified pull, of loop je er in je eigen implementatie tegenaan, laat het weten in #kring-techniek-aanspreekpunt.

Externe gremia en verzoeken

KPMG-nulmeting Landelijk Dekkend Netwerk

Status: afgerond Waar: #kring-techniek-pub

Wat het is

KPMG voert in opdracht van het team Landelijk Dekkend Netwerk van VWS een nulmeting uit naar de toegankelijkheid van het LDN. Het onderzoek kijkt niet naar één bestaande applicatie, maar naar een fictieve nieuwe toepassing als referentiepunt: een onafhankelijke data-afnemer die met toestemming van de patiënt gezondheidsgegevens uit de hele zorgketen wil ophalen via bestaande infrastructuren. Er wordt gekeken naar vier dimensies: toegang tot gezondheidsgegevens, interoperabiliteit, kaders (juridisch, organisatorisch en technisch) en kosten.

Na een eerdere validatiesessie met koepelorganisaties voert KPMG technische expertinterviews uit met partijen die een technische rol in het LDN hebben. Aan Nuts is gevraagd een technisch-inhoudelijke vertegenwoordiger te leveren. Onderwerpen: de technische inrichting, de wijze van ontsluiting, standaarden, koppelingen en de rol van de oplossing in het bredere landschap.

Opdracht

Deelnemen aan het technische expertinterview namens Nuts, en het conceptverslag van KPMG controleren op feitelijke juistheid en op de conclusies die daaruit worden getrokken.

Tijdlijn

Wanneer Wat
28 juni 2026 KPMG benadert Nuts met het verzoek
30 juni 2026 Rein Krul meldt zich als technisch-inhoudelijk vertegenwoordiger
17 juli 2026 Interview gedaan door Sergej van Middendorp en Rein Krul
Daarna Conceptsamenvatting van KPMG ontvangen en van commentaar voorzien

Resultaat

Het interview is gedaan. Op de conceptsamenvatting van KPMG zijn de volgende punten ingebracht:

Bronnen

Wat Waar
Verzoek van KPMG, 28 juni 2026 Slack, #kring-gezamenlijk-belang
Toelichting op opdrachtgever, opzet en de vier dimensies, plus de afstemming en het commentaar Slack, #kring-techniek-pub
Leidraad, achtergronddocument en de ActiZ-input aan KPMG Google Drive, gedeeld door Sergej van Middendorp
Conceptsamenvatting van het interview Google Drive, gedeeld door Sergej van Middendorp

Wie erbij betrokken zijn

Rol Wie
Interview namens Nuts Sergej van Middendorp en Rein Krul
Inhoudelijk commentaar op de samenvatting Rein Krul

Bij KPMG: Jesse van den Heuvel. Opdrachtgever bij VWS: team Landelijk Dekkend Netwerk, met Edwin van Maarseveen, Ulco de Boer en Margreet Schreurs.

Externe gremia en verzoeken

GISA-consultatie 2026

Status: loopt. Onze reactie op de consultatie is ingediend; het vaststellingstraject van de GISA loopt door. Waar: #kring-techniek-pub

Wat het is

De Architectuur voor het gezondheidsinformatiestelsel (GISA) is in openbare consultatie gebracht via het GISA Consultatieplatform. Nuts is uitgenodigd om te reageren. Diana Demmer (ActiZ) heeft ons op de consultatie gewezen in #consultatie-gis-uitgangspunten.

Nuts was bij GIS-A eerder aangehaakt, maar die deelname is gepauzeerd vanwege de tijdsinvestering en de trage start. De consultatieperiode viel volledig samen met de vakantie van de coördinator.

Opdracht

Namens de community reageren op de GISA-consultatie, met het voorstel dat te doen vanuit twee perspectieven: technisch en governance.

Tijdlijn

Wanneer Wat
16 juni 2026 Diana Demmer wijst op de instructies voor de openbare consultatie
12 juni 2026 Vraag aan de kring wie dit oppakt, met het voorstel het met twee mensen te doen
26 juni 2026 Aan de GIS-A-kant gemeld dat Nuts namens de kring Techniek reageert
Eind juni 2026 Technische review gereed, commentaar verzameld in een reviewdocument
Begin juli 2026 Review van het commentaar door Edwin de Wit
7 juli 2026 Indiening van het commentaar namens Nuts
10 juli 2026 Sluiting van de consultatie
24 augustus 2026 Nieuwe reeks werksessies GIS Architectuur aangekondigd voor de rest van het jaar, in de Social Impact Factory in Utrecht
25 augustus 2026 Extra afstemmoment om de conceptstukken voor het DTO af te ronden
27 augustus 2026 Concept-oplegnotitie GISA gedeeld, met v0.7 aan te leveren voor het DTO
31 augustus 2026 GISA v0.7 gepubliceerd op de VZVZ-wiki; v0.6 met alle opmerkingen blijft beschikbaar
2 september 2026 Behandeling van v0.7 en de oplegnotitie in het DTO
September 2026 GISA wordt vastgesteld in het Informatieberaad

Resultaat

De technische review is uitgevoerd door Rein Krul en het commentaar is verzameld in een reviewdocument. Edwin de Wit heeft het commentaar gereviewd en onderschreven. Rein heeft op 6 juli aangekondigd het de volgende ochtend in te dienen namens Nuts.

Met v0.7 is te controleren wat er met ons commentaar is gedaan; v0.6 met alle opmerkingen blijft daarvoor beschikbaar. Dat is nog niet nagelopen.

Twee punten om vast te houden voor een volgende ronde:

Uit het iWLZ technisch afstemmingsoverleg van 2 juli kwam daarnaast de constatering dat autorisatie in de huidige GISA nog onvoldoende is uitgewerkt.

Los van deze consultatie loopt de deelname aan GIS-A door: het redactieteam, de stuurgroep en het uitwerken van de transitiearchitectuur Nuts staan in het jaarplan en zijn op dit moment niet belegd. Zie het overzicht Waar we mee bezig zijn.

Bronnen

Wat Waar
Vraag aan de kring om de consultatie op te pakken, 12 juni 2026 Slack, #kring-techniek-pub
Aankondiging van indiening, 6 juli 2026 Slack, #kring-techniek-pub
Melding aan de GIS-A-kant dat Nuts reageert, 26 juni 2026 Slack, #consultatie-gis-uitgangspunten
Reviewdocument met ons commentaar Google Docs
Instructies en documenten van de consultatie GISA Consultatieplatform
Aankondiging publicatie GISA v0.7, 31 augustus 2026 mail van Frank Hendriksen
Concept-oplegnotitie GISA voor het DTO, 27 augustus 2026 mail van Ronald Bongers (VWS)
Uitnodigingen voor de werksessies en kennissessies GIS Architectuur mail van GIS-Architectuur@minvws.nl

Wie erbij betrokken zijn

Rol Wie
Technische review en indiening Rein Krul
Review van het commentaar Edwin de Wit
Review governance en regie niet belegd
Deelname redactieteam en werksessies Steven van der Vegt

Extern: Diana Demmer (ActiZ) als signalering, VZVZ als beheerder van het consultatieplatform.

Externe gremia en verzoeken

Nuts x MedMij: PoC-voorstellen

Status: gevraagd, nog niet belegd Waar: #kring-gezamenlijk-belang

Wat het is

MedMij en Nuts hebben een kwartaaloverleg. Daaruit zijn twee PoC-voorstellen gekomen, opgesteld door Bouke de Boer (product owner MedMij) en op 3 april 2026 gedeeld.

PoC 1: Gedeeld vertrouwen

MedMij heeft een eigen vertrouwensregister en eigen OAuth-profielen. Een Nuts-node die al ZIB's ontsluit werkt daar niet mee samen, terwijl die het vertrouwensmodel van MedMij technisch prima zou kunnen ondersteunen.

In de sectoren waar Nuts groot is wordt nog weinig data via MedMij ontsloten. Onder de EHDS wordt dat naar verwachting verplicht. Nuts-nodes ontsluiten via het MedMij-netwerk voorkomt dan onnodige implementatielast.

Onderzoeksvragen:

  1. Kan de DVA een verifiable credential uitgeven die gebruikt kan worden voor autorisatie op een Nuts-node?
  2. Op welke wijze kunnen de nieuwe databronnen zichtbaar worden gemaakt in het MedMij-netwerk?
  3. Welke aanpassingen moeten door Nuts gedaan worden?
  4. Past het in het vertrouwensmodel van MedMij?
  5. Welke risico's ontstaan door deze twee netwerken met elkaar te verbinden?

Rollen in de PoC. In MedMij-termen is de DVA de dienstverlener van de zorgaanbieder en de DVP die van de persoon.

Rol Wat die doet
Autorisatiedienst van de DVA Geeft een autorisatiebewijs af, bijvoorbeeld een verifiable credential, dat een PGO namens een persoon toegang geeft tot bepaalde resources
Nuts-node Accepteert het door de DVA afgegeven autorisatiebewijs en biedt API's aan
MedMij Stelselnode Neemt de endpoints en gegevensdiensten op in het MedMij-register en publiceert ze
DVP Maakt gebruik van de aangeboden Nuts-gegevensdiensten

Hoe die rollen samenwerken staat niet in het voorstel. Wij lezen het zo: de autorisatiedienst van de DVA geeft een credential uit over het mandaat van de patiënt aan het PGO om namens hem te handelen. Met die credential authenticeert het PGO zich vervolgens direct bij de Nuts-node van een zorginstelling en vraagt daar een access token op. De DVA is na uitgifte uit de loop. Dit is onze aanname en nog niet bevestigd door MedMij.

Resultaat: een rapportage met de antwoorden op de onderzoeksvragen, inclusief risicoanalyse, en een werkende PoC-omgeving met alle betrokken rollen.

Twee punten die het voorstel zelf openlaat: of we ook willen kijken of MedMij-DVA's ontsloten kunnen worden op Nuts, en dat de nieuwe gegevensdiensten waarschijnlijk niet voldoen aan de toelatingscriteria van de MedMij-catalogus.

PoC 2: Hybride netwerkzorg-chat

Onder de vlag van Nuts is eerder een PoC voor hybride netwerkzorgcommunicatie uitgevoerd, op basis van de standaard Matrix. Daarmee kon een chat worden opgezet tussen zorgverleners van verschillende organisaties, patiënten en mantelzorgers. Zorgverleners uitnodigen kan veilig, op basis van het vertrouwen dat Nuts biedt in combinatie met een adresseringsvoorziening. Hoe een burger wordt toegevoegd is niet gestandaardiseerd, en betrouwbare identificatie is daar de open vraag. De hypothese is dat het MedMij-stelsel dat kan invullen, bijvoorbeeld door de uitnodiging via een MedMij-gegevensdienst te laten lopen en de DVP of PGO als chatclient in te zetten.

Onderzoeksvragen:

  1. Hoe kan een matrix-ID van een burger via het MedMij-afsprakenstelsel worden geverifieerd op een betrouwbaarheidsniveau dat in een zorgcontext bruikbaar is?
  2. Levert dit voor de gebruiker een goede ervaring op?
  3. Welke wijzigingen in het MedMij-afsprakenstelsel en de gegevensdiensten zijn nodig?
  4. Welke functionaliteit moet een DVA daarvoor bieden?
  5. Welke afspraken zijn nodig tussen de DVA en een XIS?

Rollen: twee XIS'en, bijvoorbeeld OZOverbindzorg, waarvan de ene de chat opzet en de andere deelneemt; een DVA die de uitnodiging voor de burger klaarzet en de identificatie doet; en een DVP die een Matrix-client en -server implementeert.

Resultaat: een rapportage met de antwoorden, bevindingen en de resultaten van het gebruikersonderzoek, plus een werkende PoC-omgeving met alle rollen.

Relevantie voor Nuts

PoC 1 raakt ons rechtstreeks: de Nuts-node moet een door een MedMij-DVA uitgegeven credential accepteren, en onderzoeksvraag 3 gaat expliciet over wat wij daarvoor moeten aanpassen. Het vertrouwensmodel lijkt op dat van LSP x Nuts, dus daar valt werk te hergebruiken.

Er is geen landelijk programma waar deze koppeling onder valt. Dat is een gat in de roadmaps en tegelijk de reden dat het initiatief bij MedMij en Nuts zelf ligt.

Het is bovendien een kans om meer data voor de burger te ontsluiten, en om te toetsen of ons vertrouwensmodel ook in het burgerdomein bruikbaar is.

Belegging

Wat er nu speelt

Naast de PoC's lopen er uit hetzelfde overleg twee kleinere technische lijnen:

Te besluiten

  1. Wil de kring Techniek PoC 1 als opdracht beleggen, en zo ja bij wie en met welk tijdsbeslag?
  2. Wie brengt PoC 2 in bij de kring Toepassingen?
  3. Nemen we de door MedMij opengelaten vraag mee of ook MedMij-DVA's ontsloten kunnen worden op Nuts, of houden we de PoC eenrichtingsverkeer?

Samenhang met andere trajecten

Bronnen

Wat Waar
Voorstel "Proof of Concept: Nuts x MedMij: Gedeeld vertrouwen", 3 april 2026 mail van Bouke de Boer
Voorstel "Proof of Concept: Nuts x MedMij: Hybride netwerkzorg-Chat", 3 april 2026 mail van Bouke de Boer
Samenvatting kwartaaloverleg 7 april 2026, AI-gegenereerd en niet gecontroleerd mail van Bouke de Boer
Aantekeningen kwartaaloverleg 25 augustus 2026 mail van Sergej van Middendorp

Wie erbij betrokken zijn

Rol Wie
Opsteller van de PoC-voorstellen Bouke de Boer (MedMij)
Technische feedback vanuit Nuts Steven van der Vegt
Gezamenlijk belang en relatie met MedMij Sergej van Middendorp
Vanuit MedMij verder betrokken Carlos Villa Baars
Vanuit de leveranciers Daan Verbree (Topicus)

Het kwartaaloverleg MedMij en Nuts is het gremium waarin dit loopt.

Hoe haak je aan

Voor de technische kant: #kring-techniek-aanspreekpunt. Voor de samenwerking met MedMij: #kring-gezamenlijk-belang.

Rollen en doorlopend werk

Rollen en doorlopend werk

Beheer en doorontwikkeling nuts-node

Status: loopt Waar: #development en #releases

Wat het is

De nuts-node is het kernproduct van de community en draait in productie bij deelnemers. Beheer en doorontwikkeling staan als doorlopend werk in het jaarplan. Binnen dit werk is één rol formeel belegd: het producteigenaarschap, op 13 oktober 2025 met consent bij Rein Krul, als opvolger van Tomas Harreveld en daarvoor Wout Slakhorst. Bij dat besluit is de rol omschreven als aanspreekpunt en verantwoordelijk voor het product in de brede context: techniek, ontwikkeling en support. Wat de rol precies omvat is daarna niet uitgewerkt.

Deze pagina is een reconstructie van de bestaande praktijk, samengesteld uit de GitHub-repositories en de Slack-kanalen. Het is een beschrijving van wat er gebeurt, geen voorstel tot verandering.

Opdracht

Doel. Een nuts-node die veilig, actueel en bruikbaar is voor de partijen die hem in productie draaien, met een voorspelbaar release- en ondersteuningsbeleid.

Scope. De opdracht omvat:

Buiten scope vallen: het beheer van individuele nodes bij deelnemers, de toepassingen die op de node draaien, en het beheer van de samenwerkingsmiddelen zelf zoals de GitHub-organisatie en de toegangsrechten daarop.

Resultaat. Doorlopend werk zonder einddatum. De kring stuurt via prioritering en kaders, niet via besluiten per issue.

Belegging. Producteigenaar: Rein Krul. Ontwikkeling: Rein Krul en Steven van der Vegt. Externe bijdragen via pull requests staan open voor iedereen. De producteigenaar prioriteert binnen deze opdracht en is aanspreekpunt voor het product; het aanwijzen van mensen en het beleggen van uren is aan de kring.

Werk met een financieel gevolg dat niet in de begroting is voorzien, zoals een security scan of een groter stuk ontwikkelwerk, wordt afgestemd met de producteigenaar. Gaat het om werk van substantiële omvang, dan meldt degene die het oppakt dat in de kring. De inschatting daarvan ligt bij de betrokkene zelf; het gaat om navolgbaarheid achteraf, niet om toestemming vooraf.

Werkwijze. Vragen en meldingen komen binnen via #development en via GitHub-issues. Releases en kwetsbaarheden worden aangekondigd in #releases; node-beheerders wordt gevraagd zich daarop te abonneren. Bij functionele wijzigingen die gebruikers raken wordt eerst een voorstel in de community gelegd voordat het op de backlog komt.

De producteigenaar kan taken uit deze opdracht vrij delegeren, bijvoorbeeld tijdens vakantie of bij piekbelasting. De verantwoordelijkheid voor de rol blijft daarbij bij de producteigenaar; delegatie van de rol zelf is een besluit van de kring.

Vastgelegd beleid

Beleid dat in de praktijk geldt en dat hier expliciet wordt gemaakt:

Te besluiten

  1. Bevestigt de kring de opdracht zoals hierboven beschreven, als beschrijving van de bestaande praktijk?
  2. Welke repositories en ondersteunende software vallen onder deze opdracht, en welke zijn deprecated of niet ondersteund? Voorstel is die lijst als bijlage vast te stellen, zodat voor deelnemers duidelijk is waar zij op kunnen bouwen.
  3. Waar landen inhoudelijk-beleidsmatige besluiten over de node? Het jaarplan constateert dat besluiten over de node vaak grote impact hebben op de kring Toepassingen, maar nergens expliciet als corrigeerbaar beleidsbesluit worden genomen. Het technisch convergentieoverleg in oprichting kan hierin een rol spelen: het brengt de toepassingsverantwoordelijken en de kring bij elkaar en kan besluiten die om een kaderkeuze vragen voorbereiden voor de kring.
  4. Bevestigt de kring het beleid hierboven, zodat deelnemers zich erop kunnen verlaten?
  5. Bevestigt de kring de ontwikkelaars zoals hierboven genoemd, en hoe worden nieuwe mensen toegevoegd? Op dit moment volgt dat uit de schrijfrechten op de repositories en niet uit een besluit. Dit hangt samen met de open punten uit het jaarplan over de gedeelde ontwikkelinzet en over de vraag of de uitvoerende ontwikkeling in een subkring hoort.

Samenhang met andere trajecten

Bronnen

Wat Waar
Besluit producteigenaarschap, 13 oktober 2025 Logboek Kring Techniek
Ondersteuningsbeleid voor CVE's en minor-versies, 25 maart 2026 Slack, #development
Toelichting op major-versies en het ontbreken van v7-plannen, 7 mei 2026 Slack, #kikv-v6-migratie
Migratiedocumentatie v5 naar v6 readthedocs
Release notes readthedocs
Repositories github.com/nuts-foundation

Wie erbij betrokken zijn

Rol Wie
Producteigenaar nuts-node Rein Krul
Ontwikkeling Rein Krul en Steven van der Vegt
Achtervang Steven van der Vegt

Hoe haak je aan

Vragen over het draaien van een node en meldingen van problemen gaan naar #development. Draai je een node in productie, abonneer je dan op #releases en zorg dat de meldingen daadwerkelijk bij je binnenkomen.

Rollen en doorlopend werk

Community-tooling en samenwerkingsmiddelen

Status: loopt Waar: #kring-techniek-aanspreekpunt

Wat het is

De kring ondersteunt de community met de middelen die samenwerking en kennisdeling mogelijk maken: de wiki, de website, de code-repositories, de project-boards, Slack en de bijbehorende accounts, domeinen en certificaten. Dit staat als doorlopend werk in het jaarplan en volgt uit punt 3 en punt 5 van het mandaat.

Deze pagina is een reconstructie van de bestaande praktijk. Het is een beschrijving van wat er is en wat er gebeurt, geen voorstel tot verandering.

Overzicht van de middelen

Middel Waar het draait Waarvoor Beheer
Wiki BookStack op Google Cloud Kringpagina's, documentatie en overzichten Steven van der Vegt
Website GitHub Pages Publieke informatie over Nuts Rein Krul, ondersteunend aan de kring Gezamenlijk Belang
Code-repositories GitHub Broncode, specificaties, issues en de FHIR IG-builds van de toepassingen Steven van der Vegt (toegang en security)
Project-boards GitHub Backlog en voortgang per project volgt de repositories
Docker Hub Docker Hub Publicatie van de images Rein Krul en Steven van der Vegt
Slack Slack Dagelijkse samenwerking en community-kanalen Steven van der Vegt
Specificaties en RFC's GitBook RFC's, bolts en leveranciersspecificaties Steven van der Vegt
Node-documentatie Read the Docs Deployment- en beheerdocumentatie van de nuts-node Steven van der Vegt (omgeving), inhoud volgt het producteigenaarschap
Zorgtoepassingenkompas Vercel, met Supabase Overzicht van de status en voortgang per zorgtoepassing Edwin de Wit
Google Workspace Google Mailboxen, Docs en Drive Steven van der Vegt
Domeinnamen, DNS en certificaten TransIP als registrar nuts.nl en bijbehorende subdomeinen, de DNS-records en de certificaten daarvoor Steven van der Vegt

Van deze middelen zijn Google Workspace, Google Cloud en de domeinnamen betaald. De overige omgevingen zijn kosteloos in gebruik omdat onze software open source is.

Het Zorgtoepassingenkompas is nog in draft en loopt voorlopig als losse app. De vraag of het samengaat met nuts.nl/toepassingen ligt bij de kring Gezamenlijk Belang, omdat de website hun domein is; het onderhoud raakt deze kring.

Opdracht

Doel. Werkende, veilige en toegankelijke samenwerkingsmiddelen voor de community, met duidelijk beheer en zonder onnodige afhankelijkheden.

Scope. De opdracht omvat:

Buiten scope valt de inhoud die in deze middelen wordt gepubliceerd. Elke kring en elke opdracht is zelf verantwoordelijk voor de eigen pagina's, documentatie en berichten. De website is daarvan het duidelijkste voorbeeld: het domein communicatie en website ligt bij de kring Gezamenlijk Belang, wij leveren de technische ondersteuning. Ook de PKIoverheid- en UZI-certificaten die deelnemers voor hun eigen node gebruiken vallen hier niet onder; dit gaat om de certificaten van onze eigen omgevingen.

Resultaat. Doorlopend werk zonder einddatum.

Belegging. Zie de kolom Beheer in het overzicht hierboven.

Werkwijze. Verzoeken en storingen komen binnen via #kring-techniek-aanspreekpunt en rechtstreeks bij de beheerders. Waar een wijziging wordt aangekondigd, hangt af van wie hem merkt: bij de gebruikers van de betreffende tool, in #general als het de hele community raakt, en in de kring als het om beleid of om een structurele verandering gaat. Voor de website loopt de afstemming via #website, samen met de kring Gezamenlijk Belang.

Recent beleid

Aandachtspunten

Het Slack Pro-abonnement loopt af rond half november 2026. Eerder is besloten niet te verlengen. Er zijn drie richtingen: overgaan op het gratis plan en de historie grotendeels kwijtraken, alsnog betalen, of zelf een open source alternatief hosten zoals Mattermost of Matrix. De afweging is niet alleen financieel: de workspace heeft ruim 900 leden, terwijl een overstap naar een eigen omgeving realistisch door zo'n 60 mensen gevolgd zou worden. Dit valt onder ons mandaat, maar raakt de hele community en vraagt dus toetsing daar.

De wiki draait op een Google Cloud-omgeving en moet daar weg. Wat daarvoor nodig is: een keuze voor de nieuwe omgeving, een migratiepad met behoud van de inhoud en de links, en helderheid over wie de omgeving daarna beheert en betaalt. Vanuit project GF loopt een eigen keuze voor een hostingprovider, zie Hosting van de GF-testomgeving. Die omgeving is geen oplossing voor de wiki, maar kan er wel voor in beeld komen.

Afhankelijkheid van Google. Naast de wiki lopen ook de mailboxen, Docs en Drive via Google Workspace. Dat is geen acuut probleem, maar het is de moeite waard om te weten wat de afhankelijkheid is en wat een alternatief zou kosten, mede gezien de uitgangspunten van Nuts.

Beheer hangt op enkele personen. Vrijwel alle omgevingen worden door één persoon beheerd. Er is geen achtervang vastgelegd. Bij domeinnamen, DNS en certificaten weegt dat zwaarder dan elders, omdat een gemiste verlenging direct zichtbaar is voor de hele community.

Te besluiten

  1. Bevestigt de kring de opdracht zoals hierboven beschreven, als beschrijving van de bestaande praktijk?
  2. Wie is achtervang per omgeving, zodat beheer niet op één persoon rust?
  3. Waar gaat de wiki naartoe, en wie werkt dat uit? Voorstel is dit als aparte opdracht te beleggen, met een voorstel terug in de kring.
  4. Wat doen we met Slack als het Pro-abonnement afloopt, en hoe toetsen we dat bij de community? Dit vraagt een besluit ruim voor half november.

Samenhang met andere trajecten

Hoe haak je aan

Mis je toegang, werkt iets niet, of wil je meehelpen aan het beheer van een van deze middelen, laat het weten in #kring-techniek-aanspreekpunt.