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 vacature
Producteigenaar nuts-node Rein Krul

Subkringen en werkgroepen

Op dit moment heeft de kring geen subkringen. Twee werkgroepen zijn in oprichting.

Werkgroep Architectuur. 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.

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.

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
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
Verwijzen naar het Landelijk afsprakenstelsel Loopt #kring-techniek-aanspreekpunt
Werkgroep Architectuur In voorbereiding #kring-techniek-pub
Werkgroep Technische Convergentie (start 27 augustus 2026) In voorbereiding #zorgtoepassing-ontwerpers
Migratie naar Nuts v6 en did:web In voorbereiding #kring-techniek-aanspreekpunt
Referentie-ontwerpen per communicatiepatroon In voorbereiding #kring-techniek-pub
Vernieuwing van de technische documentatie In voorbereiding #gf-cot
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
PKIOverheid G4-transitie (per 12 november 2026) In voorbereiding #kring-techniek-pub
GISA-consultatie 2026 Afgerond #kring-techniek-pub
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)
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

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
MedMij: PoC Nuts-nodes ontsluiten via het MedMij-netwerk Technische haalbaarheid en raakvlakken #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

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 Waar: #kring-techniek-pub en #zorgtoepassing-ontwerpers

Het leidende document is het Voorstel Werkgroep Technische Convergentie. Daarin staan de exacte formulering van het gezamenlijke besluit, de opdrachten vanuit beide kringen, de resultaten en de grenzen, en worden de openstaande punten bijgehouden. 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.

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 met 27 augustus 2026 als beoogde startdatum, 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.

Planning

Wanneer Wat
Voor 27 augustus Bekrachtiging van het gezamenlijke deel in beide kringen
27 augustus 2026 Beoogde startdatum van de werkgroep
Na drie maanden 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, en loopt dat via de Werkgroep Architectuur of via tijdelijke vertegenwoordigers?

Samenhang met andere trajecten

Bronnen

Wat Waar
Voorstel Werkgroep Technische Convergentie, leidend document Google Docs
Voorstel van Edwin de Wit voor het omvormen van het zorgtoepassingsontwerpersoverleg, 5 augustus 2026 Slack, #zorgtoepassing-ontwerpers
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

Hoe haak je aan

Wil je meedenken over de convergentie tussen zorgtoepassingen of over de migratie van een specifieke toepassing, 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: in voorbereiding 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.

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. Bevestigt de kring de scheiding in drie stappen, en de belegging van opdracht 1 en 2 zoals hierboven beschreven?
  2. Welke termijn hangen we aan opdracht 1? De node-upgrade is de kritieke voorwaarde voor stap 3 en heeft nu geen einddatum.
  3. 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

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.

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:

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
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
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
Enkele weken na de zomer Eerste versie van de TA Notificaties verwacht; daarna kan de impactanalyse starten
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
Twiin over de TA Pull als generiek bouwblok ontwikkelsupplement.twiin.nl
Concept notified-pull-specificatie 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 gegeven op 19-09-2026 (zie bijlagen). 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 aan VWS gemeld dat de reactie een week later komt, uiterlijk maandag 17 augustus.

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.

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
17 augustus Verzending van de reactie namens Nuts
nader te bepalen Vervolgproces bij VWS, na te vragen in de reactie

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
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
Contact met VWS over het proces Sergej van Middendorp, namens de kring Gezamenlijk Belang

Bij VWS: Marc Hoekstra als implementatiemanager generieke functies. 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: afgerond 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
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.

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

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

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

De wiki draait op een Google Cloud-omgeving en moet daar weg. Dit is het meest concrete punt op deze pagina. 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.

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.

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.